[Zope3-dev] The Date Time and TimeZone question

[Guido van Rossum]

[Lennart]
> There seem to be a fairly standard way on unix to find timezone information.
> There is a standard way of doing it on Windows. I assume there are standard
> ways of doing the same on Macintosh. I'm pretty sure all of them are
> incompatible. :-)
> 
> If you aren't going to use the standard tools availiable on the platforms
> you are running on, you have to implement Yet Another Incompatible TimeZone
> System, and keep track of the updates and changes in time zones yourself.
> Who is going to change Python time zone database when the DST dates change
> in Elbonia?
> 
> This is not the first time in history the problems of time zones have been
> encountered. They have already been solved. I don't see why the wheel has to
> be reinvented unless there was something fundamentally flawed with all the
> old wheels. :-)

Tim already replied to this.  Let me summarize.  Python will let you
provide your own timezone support for any timezone you like.  It will
*not* be providing a built-in database with information about the
timezones of the world.  Rather, it will provide support for UTC and
"local time" as supported by the OS.  Anything else is beyond the
scope of this proposal, except that the proposal should provide
interfaces that allow someone else to solve the database problem, with
or without building on existing non-Python libraries.

Scream if you see or miss something in our API that would prevent you
or someone else from solving that problem.

[and later]
> Summary and famouts last (ha!) words on this matter:
> 
> I think Guidos proposal are excellent, except for two things.
> 1. I don't think adding 24 hours and adding 1 day should amount to
> the same thing on DST boundaries.

I think that would be too confusing for most users.  Unless you've
spent days arguing about this stuff (:-), users will have a hard time
to remember under which circumstances it is important to distinguish
between 1 day and 24 hours.  Plus, when you subtract two datetimes,
should the result be expressed in hours or in days?  It depends on the
application which you'd want, if there's a difference.  My solution
avoids that, too.

> 2. I don't see the problem with asking the operating system for time
> zone information when converting between local time an UTC.

*If* the OS has that info, I'm happy to use it.  Outside the 1970-2038
range (on Unix) though, I'll have to use something else.  Tim has
proposed to extend the current DST rules indefinitely in both
directions, similar to our use of the Gregorian calendar from the year
1 onwards.

--Guido van Rossum (home page: http://www.python.org/~guido/)