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

[Patrick K. O'Brien]

[Guido van Rossum]
>
> tzinfo objects support all the cases you need.

Cool.

> > Would it help any to store the basic timezone (25 timezones that
> > ignore DST, like GMT) separate from some kind of DST boolean/offset
> > (assuming DST is always a one hour offset)? So we would never store
> > "EDT", we would instead store "EST" with DST as True, or as GMT-5
> > with DST as True. Then local time would be the basic timezone plus
> > the DST. Syntactic sugar-coating could display "EST" with DST == 1
> > as "EDT".
>
> Please don't.  You are making so many simplifying assumptions here
> that don't match reality that you might as well abandon timezones
> altogether. :-)

Okay. ROFL. Sorry. :-)

> > The toggle then just becomes whether or not to include/exclude an
> > extra hour in certain calculations where one datetime DST is False
> > and the other's DST is True. Or when a datetime plus a delta results
> > in a different DST than the original.
>
> You'd have to know the DST regulations for each jurisdiction in the
> world.  If you'd been following this from the start, you'd know that's
> hopeless (one particular dataset pertaining to this is 12 Mb
> compressed).

I did miss out on the beginning of this issue. Sorry again.

> > I realize I know a lot less about this issue than I should.
>
> That's unclear.  You don't know much about it, but knowing more about
> it might just drive you insane -- it seems like every anal-retentive
> person in the world has a vested interest in timekeeping algorithms. :-)

Okay. Maybe I'll stop while I'm ahead (or at least not totally crazy).

> > And I apologize if it is annoying.
>
> Merely amusing. :-)

Good.

> You'll get three types, probably:
>
> date       Keeps dates only, using an idealized ("proleptic")
>            Gregorian calendar.
>
> datetime   A subclass of date that adds time of day, recorded as
>            "hh:mm:ss.micros", but no timezone info.  IOW, naive time.
>
> datetimetz A subclass of datetime that adds an optional timezone info
>            object.  If the tzinfo object is None, this behaves
>            identical to naive datetime.
>
> The tzinfo object should have at least the following methods:
>
>   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
>
>   tz.tzname(dt)     given a datetime object, returns the timezone
>                     *name* to be used corresponding to that date and
>                     time
>
> Note that the dt argument is passed so that a tzinfo object can have a
> different name and offset when DST is in effect, e.g. EST/EDT.
> Obviously some tzinfo objects may ignore this.  Sample tzinfo classes:
>
> class UTC:
>     "UTC"
>     def tzoffset(self, dt):
>         return 0
>     def tzname(self, dt):
>         return "UTC"
>
> class FixedOffset:
>     "Fixed offset from UTC"
>     def __init__(self, offset, name):
>         self.__offset = offset
>         self.__name = name
>     def tzoffset(self, dt): return self.__offset
>     def tzname(self, dt): return self.__name
>
> import time
> class LocalTime:
>     "Local time as defined by the operating system"
>     def _isdst(self, dt):
>         t = (dt.year, dt.month, dt.day, dt.hour, dt.minute, dt.second,
>              -1, -1, -1)
>         # XXX This may fail for years < 1970 or >= 2038
>         t = time.localtime(time.mktime(t))
>         return t.tm_isdst > 0
>     def tzoffset(self, dt):
>         if self._isdst(dt):
>             return -time.timezone
>         else:
>             return -time.altzone
>     def tzname(self, dt):
>         return time.tzname[self._isdst(dt)]
>
> It would be easy enough to write classes representing specific
> timezones using the rules spelled out in
> http://webexhibits.org/daylightsaving/g.html
>
> But I propose that that is up to the user.

Looks good to me. I really didn't expect all the issues to be resolved. I
just wanted some kind of framework so we could at least have a common
starting point. What you have here looks exactly like what I was hoping we
could end up with, even if my ideas were naive and foolish. Thank you very
much.

---
Patrick K. O'Brien
Orbtech