Mailman 3 August 2015 - Datetime-SIG

Re: [Datetime-SIG] DST explained visually
by Tim Peters 27 Aug '15

27 Aug '15

[Alexander] > I have edited [1] your sketch to show the UTC mappings of two local times: g > in the gap and f in the fold: (g, fold=0) maps to G0, (g, fold=1) maps to > G1, (f, fold=0) maps to F0, and (f, fold=1) maps to F1. Note that G1 < G0 > while F1 > F0. This may look arbitrary, but it follows from a consistent > rule: fold=0 is the intersection with the line that is solid (valid) before > the transition and fold=1 is the intersection with the line that is solid > (valid) after the transition. > > [1]: https://github.com/abalkin/ltdf/blob/master/dst-visual.jpg So we're switching to a boolean flag again, named solidbefore? The great advantage to that would be easy of finding via Google. While there a hundred times more hits on "python which" than on "python fold", there are still over 800,000 hits on the latter. There only 7 on python "solidbefore" although you need the quotes to cut it back from some thousands ;-)

1 0

Re: [Datetime-SIG] DST explained visually
by Guido van Rossum 27 Aug '15

27 Aug '15

On Wed, Aug 26, 2015 at 12:37 PM, Alexander Belopolsky < alexander.belopolsky(a)gmail.com> wrote: > > On Wed, Aug 26, 2015 at 3:00 PM, Guido van Rossum <guido(a)python.org> > wrote: > >> The proposal in PEP 495 adds a 'fold' flag whose value is 0 *except* for >> local times mapped from UTC period C-D; between C and D local time is >> between R and S with fold=1. (Note that the current text of the PEP has a >> flag named 'first' whose definition is the opposite; but the plan is to >> switch to fold=0. In any case it's one bit of information and it's only >> used for times between P-Q.) > > > I have edited [1] your sketch to show the UTC mappings of two local times: > g in the gap and f in the fold: (g, fold=0) maps to G0, (g, fold=1) maps to > G1, (f, fold=0) maps to F0, and (f, fold=1) maps to F1. Note that G1 < G0 > while F1 > F0. This may look arbitrary, but it follows from a consistent > rule: fold=0 is the intersection with the line that is solid (valid) before > the transition and fold=1 is the intersection with the line that is solid > (valid) after the transition. > > [1]: https://github.com/abalkin/ltdf/blob/master/dst-visual.jpg > Cool! Which reminds me, there are some edge cases to consider. What's the local time for UTC=A? And for UTC=C? I guess the rule is to use half-open intervals on the X axis that are open on the right, so that A maps to Q and C maps to R. -- --Guido van Rossum (python.org/~guido)

1 0

Re: [Datetime-SIG] DST explained visually
by Alexander Belopolsky 27 Aug '15

27 Aug '15

On Wed, Aug 26, 2015 at 3:00 PM, Guido van Rossum <guido(a)python.org> wrote: > > Note that the current text of the PEP has a flag named 'first' whose definition is the opposite; but the plan is to switch to fold=0. I decided to establish the origin of the term "fold" before editing the PEP. The credit for introducing the term "fall-backward fold" in computing goes to Paul Eggert of UCLA who used it in various discussions related to the C language standard that culminated in a defect report #139 [1]. However, apparently, the idea goes back to 1917 Germany. As Paul Eggert explained in private correspondence, """ fold=0 and fold=1 is like the longstanding German standard for expressing times as strings, which uses "A" and "B" to distinguish time stamps that would otherwise be ambiguous. If I understand things correctly, normally fold=0, but you can have fold=1 when time stamps are repeated. For more about the German standard, you can start with the Wikipedia description here: [2] """ [1]: http://www.open-std.org/jtc1/sc22/wg14/docs/rr/dr_136.html [2]: https://de.wikipedia.org/wiki/Sommerzeit#Offizielle_Regelung_der_Zeitumstel…

1 0

Re: [Datetime-SIG] DST explained visually
by Tim Peters 27 Aug '15

27 Aug '15

[Guido] > I've drawn a simple diagram showing the relationship between UTC and local > time throughout a DST cycle: > > https://www.dropbox.com/s/ptx58d9zkd7m4vj/2015-08-26%2010.28.38.jpg?dl=0 Cool! But in the spirit of mailing lists, I want to complain about the asymmetry of the labels: A, B, C, D are the first four letters of the English alphabet, so for symmetry it's just plain broken that you didn't use W, X, Y, Z for the other labels ;-) Another thing to note: as Isaac observed, while UTC->local is a function, that's not as exploitable as one might hope, because it's not a continuous function. However, the diagram as a whole shows a collection of 3 piecewise continuous bijections (each solid diagonal line segment is a one-to-one continuous function "in both directions" - and also monotonic). That's highly exploitable. Indeed, for times through 2037, tzfiles explicitly store all points akin to A and C (the UTC points bounding the piecewise continuous bijections) in a sorted list. It's a minor annoyance that there are an infinite number of such points ;-)

1 0

Re: [Datetime-SIG] DST explained visually
by Alexander Belopolsky 27 Aug '15

27 Aug '15

On Wed, Aug 26, 2015 at 3:00 PM, Guido van Rossum <guido(a)python.org> wrote: > The proposal in PEP 495 adds a 'fold' flag whose value is 0 *except* for > local times mapped from UTC period C-D; between C and D local time is > between R and S with fold=1. (Note that the current text of the PEP has a > flag named 'first' whose definition is the opposite; but the plan is to > switch to fold=0. In any case it's one bit of information and it's only > used for times between P-Q.) I have edited [1] your sketch to show the UTC mappings of two local times: g in the gap and f in the fold: (g, fold=0) maps to G0, (g, fold=1) maps to G1, (f, fold=0) maps to F0, and (f, fold=1) maps to F1. Note that G1 < G0 while F1 > F0. This may look arbitrary, but it follows from a consistent rule: fold=0 is the intersection with the line that is solid (valid) before the transition and fold=1 is the intersection with the line that is solid (valid) after the transition. [1]: https://github.com/abalkin/ltdf/blob/master/dst-visual.jpg

1 0

DST explained visually
by Guido van Rossum 27 Aug '15

27 Aug '15

I've drawn a simple diagram showing the relationship between UTC and local time throughout a DST cycle: https://www.dropbox.com/s/ptx58d9zkd7m4vj/2015-08-26%2010.28.38.jpg?dl=0 tl;dr: Timeline arithmetic moves along the X axis (UTC); classic arithmetic moves along the Y axis (local time). Discussion: On the X axis I've drawn UTC. On the Y axis I've drawn local time. Ignoring most of the interesting bits, we observe that the mapping from UTC to local time is a function -- for each UTC value there is exactly one correct answer to the question "what is the local time". If we didn't have DST, the plot would be a single straight line at an angle of 45 degrees, i.e. the identity function (y = x). Regardless of the exact function, mapping from local time back to UTC is done by looking up the local time on the Y axis, going right parallel to the X axis until you hit a point on the graph, and then going down to the X axis. What you find there will be UTC. The interesting (and confusing) part is that with DST (or other changes that move local time back) *the inverse is no longer a function*. Let's look at DST in detail. There are four interesting points along the X (UTC) axis: A, B, C, D. I've also drawn four interesting points along the Y (local time) axis: P, Q, R, S. For simplicity, I am assuming DST moves the clock forward by one hour. However, as the diagram is not labeled in absolute units, the individual transitions can also be used to discuss other transitions (e.g. the areas around A could be used to discuss a non-DST-related timezone adjustment, or C-D could represent a leap second). Points along the UTC (X) axis: (A) Start of DST; local clock is move one hour forward. This moves local time from P to Q. (B) One hour before the end of DST. This is the beginning of a period in UTC where mapping to local time and back can cause ambiguities. Note that the period A-B is in reality several months (e.g. from some time in March or April till some time in October or November, in the northern hemisphere). (C) End of DST; local clock is moved one hour back, moving local time from S to R (!). (D) One hour after the end of DST. This is the end of the UTC period where ambiguous local times matter. Points along the local time (Y) axis: (P) Local standard time when DST starts; local clock moves one hour forward, from P to Q in an instant. (Q) Local daylight saving time at the start of DST. (R) Start of ambiguous local time. (S) End of ambiguous local time. The first time we hit this point we move the local clock back by one hour (to R). The second time we hit this point we do nothing. The proposal in PEP 495 adds a 'fold' flag whose value is 0 *except* for local times mapped from UTC period C-D; between C and D local time is between R and S with fold=1. (Note that the current text of the PEP has a flag named 'first' whose definition is the opposite; but the plan is to switch to fold=0. In any case it's one bit of information and it's only used for times between P-Q.) It may not be obvious from the diagram, but by taking the fold flag and the rest of the local time together, the mapping from local time (augmented with the fold flag) to UTC is once again a function, at least in the domain R-S (the fold). In the gap (P-Q) the inverse has no value; but PEP 495 extends the meaning of the fold flag to assign a meaning here too, by mapping P-Q with fold=0 to the extension (up and to the right) of the plot of standard time, and P-Q with fold=1 to the extension (down and to the left) of the plot of DST. (The diagram doesn't label the relevant points but there are dotted lines representing these extensions). My final observation is that the distinction between classic and timeline arithmetic is simply the distinction between the two axes of the plot: timeline==X, classic==Y. Both are useful in different contexts. -- --Guido van Rossum (python.org/~guido)

1 0

Re: [Datetime-SIG] The name of the UTC timezone
by Guido van Rossum 27 Aug '15

27 Aug '15

OK, I guess we can change stdlib datetime.timezone.utc's str() to 'UTC'. Make sure to update both the C and the Python version, and the tests, and the docs. It's going to have to go into 3.6. On Wed, Aug 26, 2015 at 9:38 AM, Alexander Belopolsky < alexander.belopolsky(a)gmail.com> wrote: > > On Wed, Aug 26, 2015 at 12:30 PM, Guido van Rossum <guido(a)python.org> > wrote: > >> Why is this needed? When would a real app use %Z%z? > > > Given that a bug report [1] exists, someone was tripped by the current > behavior. It is my understanding that "UTC" is one of the few timezone > abbreviations that we recognize in strptime and the users expect strptime > to be able to parse whatever strftime produces. > > > [1]: http://bugs.python.org/issue22241 > -- --Guido van Rossum (python.org/~guido)

1 0

Re: [Datetime-SIG] The name of the UTC timezone
by Tim Peters 27 Aug '15

27 Aug '15

[ Guido] > Why is this needed? When would a real app use %Z%z? [in strftime] I've seen it often, and I'm not even a timezone wonk ;-) "The problem" it solves is for programmers who deal with lots of timezones. The name alone is ambiguous in some cases, and so is the offset alone. The offset alone is enough to convert that single instance to UTC, but that's not the only thing someone seeing the output may want to know (else nobody would ever display the name).

1 0

Re: [Datetime-SIG] The name of the UTC timezone
by Alexander Belopolsky 27 Aug '15

27 Aug '15

On Wed, Aug 26, 2015 at 12:30 PM, Guido van Rossum <guido(a)python.org> wrote: > Why is this needed? When would a real app use %Z%z? Given that a bug report [1] exists, someone was tripped by the current behavior. It is my understanding that "UTC" is one of the few timezone abbreviations that we recognize in strptime and the users expect strptime to be able to parse whatever strftime produces. [1]: http://bugs.python.org/issue22241

1 0

Re: [Datetime-SIG] The name of the UTC timezone
by Guido van Rossum 27 Aug '15

27 Aug '15

Why is this needed? When would a real app use %Z%z? On Wed, Aug 26, 2015 at 7:01 AM, Alexander Belopolsky < alexander.belopolsky(a)gmail.com> wrote: > As a little diversion from the PEP wars, let me ask the group if we can > fix this little wart: [1] > > >>> from datetime import * > >>> t = datetime.now(timezone.utc) > >>> print(t) > 2015-08-26 13:37:18.729831+00:00 > >>> t.strftime("%F %T %Z%z") > '2015-08-26 13:37:18 UTC+00:00+0000' > > The reason for such an odd result is that the "name" of timezone.utc was > defined as > > >>> t.tzname() > 'UTC+00:00' > > I don't think there was any deep reason for this choice. We simply have > one common rule for forming the names of all fixed offset timezones that > don't have a name supplied in the constructor: > > >>> print(timezone(-5*HOUR)) > UTC-05:00 > > For technical reasons, we cannot give timezone.utc a name, but I think we > can change the rules for forming fixed offset timezone names so that zeros > are not printed and instead of > > >>> print(timezone(0*HOUR)) > UTC+00:00 > > we have > > >>> print(timezone(0*HOUR)) > UTC > > > [1]: http://bugs.python.org/issue22241 > > _______________________________________________ > Datetime-SIG mailing list > Datetime-SIG(a)python.org > https://mail.python.org/mailman/listinfo/datetime-sig > The PSF Code of Conduct applies to this mailing list: > https://www.python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido)

1 0