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

[Phillip J. Eby]

At 09:53 AM 3/17/02 -0500, Guido van Rossum wrote:
>[Phillip]
> > If it is a 'datetimetz' with a different tzinfo than 'tz', then
> > presumably tz must convert 'dt' to UTC or its own time system first.
> > Since it can ask the other tzinfo object for a UTC offset for 'dt',
> > it provably can perform this conversion.
>
>I hadn't thought of this case at all.  The intended use of these
>methods was to provide tz-related information for a datetimetz
>referencing tz.  I'm not sure I like this interpretation, though,
>because of what you said next:
>
> > Of course, if 'tz' is a constant offset, then there's no need to
> > look at the value of 'dt' at all.  :)
>
>...which is what my example classes UTC and FixedOffset did.  But this
>wouldn't be correct under your interpretation!

Actually, it would.  If the offset is constant, it doesn't matter what 'dt' 
is, as tzoffset() will return the same value for any value of 'dt'.



>   I like my
>interpretation better: tz info attached to the datetime object is
>*ignored* and the year/month/day and hour:minute:second are
>interpreted as if they were expressed in tz's local time.

Hm.  Based on the now-more-clearly-defined-below purpose of tzoffset(), I 
would prefer that it be required to raise an exception if it is passed a 
datetimetz with a different, non-None tzinfo.  This makes tzoffset() 
useless for conversion, but it sounds like you don't intend tzoffset() to 
be used for conversion, so that's okay.  Ignoring the tzinfo on a 
datetimetz when tzoffset() depends on the value of the datetime sounds like 
an invitation for nasty errors to creep in.


> > IMHO, for ease of conversion, it would be better if tzinfo objects
> > supported methods to return a datetime (or at least the datetime
> > field values) from a linear time value (such as Unix clock ticks),
> > and vice versa.
>
>Conversion of times between different timezones is a different issue
>for which I haven't designed an API yet.

Ah.  That's what I thought tzoffset() was for.  I did think it was a rather 
unusual way of approaching the problem.  :)