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

[Guido van Rossum]

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

[Phillip]
> 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'.

Hm, but the semantics would not be what you described above (because
it wouldn't do the tz conversion that you suggested the semantics
could do).

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

Good plan.  I've updated the Wiki.

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

:-)

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