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

[Guido van Rossum]

[Guido]
> > The example in this page:
> > 
> >   http://www.zope.org/Members/fdrake/DateTimeWiki/NaiveTime
> > 
> > is far from complex.  It only involves one time in one timezone,
> > and asks the question what should happen if we add a whole number
> > of days across a DST jump.  Re-read the page before you reply,
> > please.

[Hannu]
> As I already replied on that wiki, an elegant way to give the time
> delta explicit precision - if we add one day whe just operate on
> days, if we add 24 hours then we compute in UTC and convert back to
> whatever tz we had. if we need 2days and3 hour later we do (D +
> 2days) + 3 hours.
> 
> Else there is no way to do some ops, like adding 1 month - there is
> no one value for one month in days or hours or seconds, it _only_
> makes sense in *months*.

I think that precision is not the concept you're looking for.  If you
told me the precision of a date was given in months, I would assume
that the day of the month is indeterminate.  Adding something with a
precision of a month to a specific date would yield something with a
precision of a month, e.g. "April 1st, 2002 12:00:00" plus 2 months
would yield "June 2002" -- no day or time.

The "problems" relating to adding 1 month to e.g. January 31 are well
understood -- sensible people agree that this should yield the last
day of February that year.  This can be defined exactly without
referring to precision -- all you need to do is specify relative time
as a (months, days, seconds) tuple.  (Note that adding a year uses the
rules for adding 12 months, so Feb 29 + 1 year becomes Feb 28 the next
year.)

> Doing it this way also quietly removes most problems of leap seconds
> and and leap years (or rather pushes them into conversion routines
> from/to Universal Seconds or whatever)

Again, there's no need.  Also, heaping leap seconds and leap years in
the same category is a mistake -- leap years are defined by an
algorithm that can easily be calculated aeons in the future; leap
seconds are determined by observation of irregularities in the earth's
orbit, and are mostly unpredictable.

> And I think that at least days-in-month should also take negative
> values (like current array indexes), so that
> 
> 2002.02.-1 == 2002.02.29
> 
> 2002.02.-1 + 1MO == 2002.03.-1 == 2002.03.31
> 
> 2002.02.-1 + 2Y == 2004.02.-1 == 2004.02.29

That's probably a good notational convention.

> Or perhaps TZ should not be a subclass at all but rather a Viewer
> object of DateTime object so that the same DateTime can be viewed in
> several timezones

But that assumes that the original time has a specific TZ attached to
it.  Naive time doesn't commit to a specific TZ, and you have to
provide a specific TZ offset to determine what it means in UTC.

My solution for that problem would be different: I'd provide a way to
convert a datetimetz object to another datetimetz object that
represents the same UTC time but attaches a different tzinfo object.

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