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

[Tim Peters]

[Patrick K. O'Brien]
> Take a look at the sample tzinfo classes here:
> http://www.zope.org/Members/fdrake/DateTimeWiki/TimeZoneInfo

That's where this started; the text that got snipped contained the first
example from that page verbatim.

> What you seem to be arguing for

I'm not arguing for anything here -- I'm just trying to understand what
Guido is trying to say, whether it makes sense, and whether it's useful.  It
doesn't help that there are, so far, no concrete examples of use.  The words
are floating out in space.

> sounds remarkably like the FixedOffset class.

The counterexample UTC class I gave did return a fixed offset, so that's why
it sounded that way.  I could have picked a more convoluted example, but
figured this would be painful enough with the simplest variant possible
<wink>.

> Whereas, implied by its name and intent, the UTC class *is* meant to
> an offset of 0 from UTC.  But neither has anything in particular to do
> with naive time, as both are allowed to be combined with a naive time
> in a datetimetz object.

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.

    now = datetime(2002, 3, 15, 21, 16)

is a specific datetime object, and UTC().tzoffset(now) is not at all telling
me now's "timezone offset in seconds east of UTC" unless I assume now is a
UTC time to begin with.  Is that clearer?  I'm not arguing anything "in the
abstract", I'm trying to figure out what the existing words *mean*.

Perhaps it's trying to say that a tzinfo *specifies*, rather than reveals,
the tzoffset corresponding to a given datetime.  That even appears likely
now.  But even in that case, it's unclear why the sample classes ignore
whatever tzinfo object may be attached to their dt argument if dt is a
datetimetz instance.

I'm afraid this just isn't going to make sense to me until I see concrete
examples of intended use.

> Your suggestion ...

What is the suggestion you believe I made?  The only one I believe I made
was that we become explicit about assumptions.