[Zope3-dev] The Date Time and TimeZone question

[Guido van Rossum]

[Lennart Regebro]
> I don't see the need of *storing* the state of DST at all.
> A timezone aware DateTime object stores two things:
> 1. The date and time in UTC.

In my design, it stores the date and time AS THE CLOCKS IN THAT
TIMEZONE WOULD SHOW.  This makes displaying the time easier.

> 2. The timezone.

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).  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().

> If the timezone is a timezone that has DST, weather or not DST is in
> effect is entirely dependant on what the date and time is, and is
> therefore calculated when the conversion from the UTC to the local
> time is done, which is only done when displaying the date, or making
> date based additions and subtractions.

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.

The only situation where the tzinfo object is consulted are
subtracting or comparing two datetime objects that don't have the same
tzinfo object -- then conversion to UTC is done and the
subtraction/comparison is (conceptually) done on the UTC times.

> I can see there is a long discussion about this. I missed out the
> start of it, but to be brutally honest I don't think it is half as
> complicated as you think. Yes, adding and subtracting time of DST
> boundaries is complicated, but I think Guido already put forward the
> solution to that: The add/subtract function has (at least) the
> possibility of separately adding months, days and seconds.

NO!  That's not my solution at all.  See description above.

> So by adding 24*60*60 second, you move forward 24 hours. By adding
> one day, you move forward 23, 24 or 25 hours, depending on what date
> it is.

No, that's not how it works.  In my design, 1 day is exactly
equivalent to 24 hours.  You can decide on the semantics by using
different tzinfo objects, but the semantics don't affect how the
calculation is done: they only define how the translation between
"local time" (relative to the tzinfo object) and UTC is done.

> In fact, I would like to be able to have date time objects
> where you can set all of the date parts to 0. That way you can have
> a date time of 0000-01-03 00:00:00.00, which if you add it to
> another date time moves you forward one month and three days. This
> *may* be overkill, and it doesn't handle weekdays, so I'm not sure
> it's a good idea, but I like it.

Sorry, yuck.  You can't add two dates, period.  My design uses a
separate timedelta object which represents an exact number of
microseconds -- added to the "naive" time as explained above.

For calculations like "give me the First Sunday in April" and "add one
month" we'll provide a few separate methods; the latter
(adding/subtracting months) is the only special case that isn't
handled properly by imedelta objects.  But it is independent from
timezone and DST considerations.

> Converting between UTC and local time is also a complex subject. But
> both unix and windows have functional solutions for this so that it
> only is a question about calling a library function, and hence we
> need not to care much about that.

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).

> At least, I *assume* unix' solution for this is functional.  I
> haven't used it, but I have read about it and it seems very
> functional, and much more capable than Windows solution (which still
> is functional).

Sorry to disappoint you. :-)

> If there are any other problems, could somebody please summarize
> what these problems are?  The discussion here is confusing me. :-)

You're not the only one.  I wish I could summarize everything in the
Wiki, but there's too much to say so I'm lagging behind.

The good news is that the picture in my head is clearing up, so I will
eventually be able to write it down.

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