[Datetime-SIG] Are there any "correct" implementations of tzinfo?
random832 at fastmail.com
Mon Sep 14 15:30:43 CEST 2015
On Mon, Sep 14, 2015, at 04:27, Laura Creighton wrote:
> I find this totally unacceptable. My conclusion was that hybrid tzinfo
> objects were a _really stupid idea_ proposed by somebody who
> the problem, or rather only understood the most common case.
"Hybrid tzinfo objects" _in isolation_ are not bad. The problem isn't
the objects themselves, it's the whole design:
1. Hybrid tzinfo objects
2. Attached tzinfo object as the _only_ way to identify the timezone of
a datetime (no offset member)
3. Datetime itself stored in local time.
There's a reason that other languages store the offset explicitly -
because it causes the datetime+offset object to uniquely identify a
specific moment in time, and _without_ having to call in to any complex
logic [i.e. the tzinfo object's utcoffset method]. Normalizing the
results of "classic arithmetic" could (and should) be solved by
providing a hook that calls a method on the tzinfo object to find the
new offset for the result of the operation.
A "hybrid tzinfo object" is itself, in principle, exactly the same kind
of thing that, in C, is returned by tzalloc and used by localtime_rz, on
systems that have those functions. The difference is, this object is
explicitly managed rather than being "attached" to struct tm objects.
More information about the Python-list