[Zope3-dev] RE: [Python-Dev] Holes in time

[Tim Peters]

[Guido]
>> A goal of the new datetime module is to avoid all dependency on the
>> C library's time facilities -- we must support calculataions outside
>> the range that the C library can deal with.

[M.-A. Lemburg]
> I don't see how that can be done for time zones and DST.

You may be missing that datetime supplies no time zone classes, not even a
class for UTC.  What it does provide is an abstract base class (tzinfo), and
a protocol users can follow if they want to supply concrete time zone
subclasses of their own.  datetimetz.astimezone() is a pretty general tz
conversion routine that works with the tzinfo protocol, but datetime
supplies no objects astimezone can work *with* out of the box.

The time zone rules a user can support are thus whatever can be expressed by
arbitrary user-written Python code -- but they have to write that code
themself (or talk someone else into writing it for them).

> Timezones and even more the DST settings change more often
> for various locales than you think, so assumptions about the
> offset between UTC and local time for the future as well as
> for historical dates can easily be wrong.

Since the datetime module supplies no concrete time zone objects, it makes
no concrete time zone assumptions <wink> (whether about past, present, or
future).

> The tz data used by most C libs has tables which account for many
> of the known offsets in the past; they can only guess about
> the future.

A user who wants to use such tables will have to write Python code to read
them up.  If they want their code to search the web for updates and
incorporate them on the fly, they can do that too.

> The only usable time scale for historic and future date/time
> is UTC. The same is true if you're interested in date/time
> calculations in terms of absolute time.

Users who buy that can pay for it <wink>.  Note that datetime doesn't
support years outside the range 1-9999, so its appeal to astronomers and
ancient history buffs is limited anyway.

> Now, for current time zones, the C lib is a good source
> of information, so I don't see why you wouldn't want to
> use it.

As with all the rest here, users are free to, if that's what they want.
datetime just supplies a framework for what are essentially pluggable time
zone strategy objects.