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

[Guido van Rossum]

[Tim]
> >OK, what's the intent?  The page says
> >
> >     tz.tzoffset(dt) - given a datetime object, returns the
> >     timezone offset in seconds east of UTC (negative west of UTC)
> >     corresponding to that date and time
> >
> >I expect the docs don't mean what they appear to say, or are
> >leaving too much unsaid.  "That date and time" doesn't *mean*
> >anything concrete unless you tell me the time system it's measured
> >in.

[Phillip]
> IIUC, 'dt' is to be interpreted as being in tz's time system if it
> is a plain 'datetime' as opposed to a 'datetimetz'.

Yes.  Ditto if it's a datetimetz whose tzinfo is tz.

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

I'll add this to the Wiki.

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

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