[Zope3-dev] The Date Time and TimeZone question

[Lennart Regebro]

From: "Tim Peters" <tim@zope.com>

[Patrick K. O'Brien]
> > So we would never store "EDT", we would instead store "EST" with DST
> > as True, or as GMT-5 with DST as True. Then local time would be the
> > basic timezone plus the DST. Syntactic sugar-coating could display
> > "EST" with DST == 1 as "EDT".
>
> Guido doesn't like this, but I expect your basic intuition is correct:
DST
> is not part of timezone

Of course it's possible to theoretically discuss timezones as being a 4.5
hour offset, or EST without the DST, but in practice people are living in
some physical place on the earth, and that place has a timezone, and that
timezone may or may not have daylight saving, and that daylightsaving goes
on and off at a specified time. The existance or non-existance of daylight
saving, and when it goes on or off, is therefore very much a part of any
practical use of the timezone.

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.
2. The timezone.

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.


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

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

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