[Zope3-dev] Can we remove ZopeLegacy for now?

[Guido van Rossum]

> Okay. I've read the NaiveTime page. It seems to me that the real
> problem is Daylight Savings Time (DST) and not necessarily
> timezone. Would you agree?

Yes.

> If there were no such thing as DST, would you still feel that
> timezone "makes decent time arithmetic impossible"?

No, and I would approve of proposals to abolish DST.  But I doubt
it's realistic. :-)

> If not, and it really is DST that is throwing a wrench in the works,
> would it make sense to have the base datetime object deal with
> timezones in a DST ignorant way, and leave it up to a subclass to
> add the DST handling, rather than dropping timezones altogether?

Alas, no.  DST is an intrinsic part of the concept of "local time",
and timezone support that doesn't handle local time isn't very useful.

However, after another discussion with Jim Wednesday, we've been
convinced to at least provide a datetime subtype that supports
timezones in some way.

One possibility is to allow date/time calculations (e.g. adding 7 days
and 2 hours) only on naive time, and to use times with timezones
essentially as timestamps only.

Another possibility is to adopt Phillip Eby's "tzinfo object" idea.  I
had an epiphany last night about how the tzinfo object can save
date/time calculation semantics.  The trick is to do all calculations
using the naive time info only, but attach the same tzinfo object to
the result that was used for the input.  Then you could choose the
desired semantics of your calculations by picking a tzinfo object, as
follows:

- No tzinfo object would imply the naive result

- A tzinfo object representing a fixed timezone would imply the strict
  result (which ignores DST); this would also work for UTC

- A tzinfo object representing the concept of "local time in some
  locality" would do the right thing for that locality (except that
  there's one one per year where the results might be ambiguous)

I like this idea.  I almost like it enough to make the tzinfo object
part of the datetime base class, rather than relegating it to a
subclass.

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