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

[Patrick K. O'Brien]

Tim Peters wrote:

[snip]
>
> That's the tip of the zoneburg.  Guido's idea of a "naive time" base class
> ignores all of that, and *I* think is essential to sanity for people who
> just don't care to deal with this mess and its attendant surprises.  That
> doesn't mean we wouldn't be happy to supply TZ/DST support in a subclass,
> and note that Python 2.2 makes it possible to do efficient subclassing at
> the C level.
>

I feel a need to at least try to make a case for some level of timezone
support in datetime, even if that support is limited. To me, limited
functionality is better than no functionality. Why? Because, like it or not,
I have applications that need to be timezone aware. I don't mind if I have
to deal with leap years/seconds or DST issues myself, but if I have to deal
with all timezone issues myself, then datetime isn't helping me as much as
it could.

I've read the wiki pages and much of the discussion on python-dev, and I'm
actually not sure what the real issues are with timezone support. I've seen
the incredibly complex examples concerning adding datetimes from different
timezones across DST boundaries and such. And I'm sure those are a real
pain. What I haven't seen is how far one can go with a timezone aware
datetime before you run into problems.

For example, let's assume we have a datetime with timezone but without any
notion of leap seconds or DST. Now, it seems to me that this datetime can
support just about any calculation with a delta value because the timezone
remains fixed. Right? If I add or subtract a certain number of days or hours
or seconds, I don't expect the timezone to change. I expect it to remain
constant. So that shouldn't be a problem.

Then we get into issues like adding and subtracting months and how to deal
with the fact that months aren't all of a common length. But this issue is
completely separate from whether or not timezones are involved. (Again,
ignoring DST issues.)

Next, I want to be able to represent a datetime in some other timezone.
Again, this doesn't seem all that difficult and I believe the prototype
already supports this. And while it would be easy enough for a subclass to
do the conversions, somehow it seems like life will be much more difficult
if the underlying datetime didn't have the bits to store the timezone.

That leaves us with calculations involving two datetime values. For this, it
seems like we could convert the two values to a common timezone and perform
the calculation. The result should be the same as calculations between two
datetimes that had no knowledge of timezone (naive datetime).

What about applications that don't care about the timezone? It would be nice
if some notion of "no zone" or "unspecified zone" or "local zone" were
supported. This could even be the default for cases where a timezone wasn't
specified. In a way, this would be similar to "naive datetime". The
difference is that a specific timezone could be assigned later, or the
timezone could default to the local timezone. But this is different from
"naive datetime" in that datetime would still be timezone aware, even if a
specific instance lacked a specified timezone value.

So, what am I overlooking? Is there a list of "attendant surprises"
somewhere? Where do my arguments come up short? Or does some of this (I
hope) make sense? Is there any hope for timezones in datetime?

---
Patrick K. O'Brien
Orbtech