[Zope3-dev] Re: [Python-Dev] Holes in time

[Tim Peters]

[Shane Hathaway]
 > I was working on a possible solution when I stumbled across the fact
> that the current tzinfo documentation doesn't seem to specify whether
> the dst() method expects the "dt" argument to be in terms of UTC or
> local time.

I'm not keeping the plain-text docs up to date anymore, but the doc.txt
under Zope3's src/datetime/ sez:

    An instance of (a concrete subclass of) tzinfo can be passed to
    the constructors for datetimetz and timetz objects.  The latter
    objects view their fields as being in local time, and the tzinfo
    object supports ...

    ...

    These methods are called by a datetimetz or timetz object, in
    response to their methods of the same names.  A datetimetz object
    passes itself as the argument, and a timetz object passes None
    as the argument.  A tzinfo subclass's methods should therefore be
    prepared to accept a dt argument of None, or of class datetimetz.

    When None is passed, it's up to the class designer to decide the
    best response.  For example, ...

    ...

    When a datetimetz object is passed in response to a datetimetz
    method, dt.tzinfo is the same object as self.  tzinfo methods can
    rely on this, unless user code calls tzinfo methods directly.  The
    intent is that the tzinfo methods interpret dt as being in local
    time, and not need to worry about objects in other timezones.

So I can't tell you what *your* dst() method should expect if you call it
directly, but I can (and do) tell you that whenever the implementation calls
a tzinfo method by magic, the argument will be None, or a datetimetz with a
matching tzinfo member and is to be viewed as local time (hmm -- perhaps the
distinction between self's notion of local time and your own notion of local
time remains unclear).

> ...
> Once that's decided, it seems like the "hard" case (whichever is the
> hard one) could be solved by first computing the UTC offset at the time
> requested, then computing the UTC offset at a time adjusted by the
> offset.  If the two computed offsets are different, you know you've
> straddled a daylight savings boundary, and maybe the second offset is
> the correct offset.  That's just a guess.

For a formal proof <wink>, see the long comment at the end of Zope3's
src/datetime/_datetime.py (which I keep in synch with the Python sandbox
version Guido pointed you at).

> feebly-trying-to-catch-up-to-tims-genius-ly y'rs, Shane

It's a lousy 3-segment step function.  This isn't genius, it's just a
stubborn refusal to give up <0.7 wink>.

if-you're-on-an-irritating-project-it's-energizing-to-attack-
    a-piece-of-it-you-hate-ly y'rs  - tim