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


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

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

Started byRandom832 <random832@fastmail.com>
First post2015-09-14 15:44 -0400
Last post2015-09-14 15:44 -0400
Articles 1 — 1 participant

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 15:44 -0400

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

FromRandom832 <random832@fastmail.com>
Date2015-09-14 15:44 -0400
SubjectRe: [Datetime-SIG] Are there any "correct" implementations of tzinfo?
Message-ID<mailman.559.1442260353.8327.python-list@python.org>
On Mon, Sep 14, 2015, at 15:25, Alexander Belopolsky wrote:
> This is a fine attitude when you implement your own brand new datetime
> library.  As an author of a new library you have freedoms that developers
> of a 12 years old widely deployed code don't have.

I'm talking about the real behavior of datetime as it exists *today*,
and has existed for the past 12 years, before any of this "add fold flag
but sort 2:15 fold1 before 2:45 fold0" nonsense gets in. It is an
invariant that is true today, and therefore which you can't rely on any
of the consumers of this 12 years old widely deployed code not to assume
will remain true.

Enforcing an invariant that all ordering is done according to UTC
timestamps would not break any backward compatibility, because there is
not a *single* pair of timestamps that can be represented today with any
*remotely* plausible tzinfo whose order is different from that. For that
matter, a tzinfo where two possible values for fold aren't sufficient to
disambiguate timestamps is *more* plausible than one where the naive
ordering of any two non-fold timestamps is reversed from the UTC order,
yet that case apparently isn't being considered.

[toc] | [standalone]


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


csiph-web