[Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation is ready for pronouncement

Random832 random832 at fastmail.com
Sat Sep 12 04:00:30 CEST 2015


Alexander Belopolsky <alexander.belopolsky at gmail.com> writes:
> Yes, but it does that at the cost of introducing the second local
> "01:30" which is "later" than the first "01:40" while "obviously" (and
> according to the current datetime rules) "01:30" < "01:40".

The current datetime rules, such as they are, as far as I am aware,
order all aware datetimes (except spring-forward) according to the UTC
moment they map to. I'm not sure what the benefit of changing this
invariant is.

>     Out of curiosity, can "fold" ever be any value other than 0 or 1?
>
> Thankfully, no.

What happens, then, if I were to define a timezone with three local
times from the same date? None may exist now, but the IANA data format
can certainly represent this case. Should we be talking about adding an
explicit offset member?  (Ultimately, this "fold=1 means the second one"
notion is a novel invention, and including the offset either explicitly
a la ISO8601, or implicitly by writing EST/EDT, is not)

>
>     > Yes, but are we willing to accept that datetimes have only
>     partial
>     > order?
>     
>     I apparently haven't been following the discussion closely enough
>     to
>     understand how this can possibly be the case outside cases I
>     assumed it
>     already was (naive vs aware comparisons being invalid).
>
> Local times that fall in the spring-forward gap cannot be ordered
> interzone even without PEP 495.

Hmm. If these have to be allowed to exist, then...

What about ordering times according to, notionally, a tuple of (UTC
timestamp of transition, number of "fake" seconds "after" the
transition) for a spring-forward time?

Also, can someone explain why this:
>>> ET = pytz.timezone("America/New_York")
>>> datetime.strftime(datetime.now(ET) + timedelta(days=90),
...                   "%Y%m%d %H%M%S %Z %z")
returns '20151210 214526 EDT -0400'

I don't know if I expected 214526 or 204526, but I certainly expected
the timezone info to say EST -0500. If EST and EDT are apparently two
distinct tzinfo values, then what exactly would a value landing near the
"fall back" transition have given for fold? fold=1 but EDT?

And if EST and EDT are, against all rationality, distinct tzinfo values,
then when exactly can fold ever actually be 1, and why is it needed?



More information about the Python-Dev mailing list