[Zope3-dev] The Date Time and TimeZone question

Lennart Regebro lennart@torped.se
Sat, 16 Mar 2002 17:31:21 +0100


From: "Guido van Rossum" <guido@python.org>
> In my design, it stores the date and time AS THE CLOCKS IN THAT
> TIMEZONE WOULD SHOW.  This makes displaying the time easier.

Yes, thats probably better. Less conversions that way.

> There are too many things that "the timezone" could mean (e.g. the C99
> standard uses it as a synonym for an offset from UTC).

Well, when I say timezone, I in this case mean something that the timezone
translation recognizes as a timezone. :-)

> I want it to
> store a reference to a "tzinfo" object which answers to at least the
> methods tzoffset() and tzname(), both of which take a datetime object
> as an argument.  It should probably also have a third method,
> tzisdst().

That sounds like a reasonable implementation. As long as the offset isn't
stored together with the datetime I'm happy.

> In my view, design, the add/subtract code can be ignorant of the
> specific rules implemented by the tzinfo object used -- it does its
> computation on the broken-out fields (which, as I said, are stored in
> the tzinfo object's local time) and simply gives the result the same
> tzinfo object as the source.

Exactly.

> No, that's not how it works.  In my design, 1 day is exactly
> equivalent to 24 hours.

I don't see how that is possible with the description you have given of your
solution.
If you make computations on the broken-out fields without taking care of
timezone information adding 1 day at a DST boundary would mean 23 or 25
hours. But, in your description adding 24 hours would always be equivalent
to adding 1 day.
I personally think that it would be of great significance if we fix this
problem, and it shouldn't even be very complicated. It does mean that you
need to convert the datetime to UTC before adding minutes or hours, and then
convert it back. But that would solve it.

> Again, emphatically, no.  Our specs require us to support this
> conversion for a much wider range of years than the C library on most
> Unix systems supports (1970-2038).

The specs I have seen for timezone support on unix date back far beyond
1970.