Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #96568 > unrolled thread

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo? Random832 <random832@fastmail.com> - 2015-09-14 09:30 -0400

#96568 — Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

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.

[toc] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web