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 > misunderstood > 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. -- https://mail.python.org/mailman/listinfo/python-list
