Mailman 3 June 2016 - Datetime-SIG

Re: [Datetime-SIG] PEP 495 and the hardest problem in computer science
by Alexander Belopolsky June 29, 2016

June 29, 2016

On Wed, Jun 29, 2016 at 4:05 PM, Random832 <random832(a)fastmail.com> wrote: > > Note that the result of conversion to UTC is different for t0 and t1 > > when they are interpreted as NY times, but the same when they are > > interpreted as London time. > > I'm pretty sure you just proved *my* point - that the flag is > meaningless outside of the timezone the time was originally created for > [or timezones that happen to have an identical fold] - so maybe I didn't > explain it clearly in the first place. > It is not meaningless. It is used to detect whether a datetime instance is special in the system timezone. > > It seems to go against the concept of a naive time to contain data that > is only relevant to some specific timezone. Yes, there was some resistance to the notion that naive may mean system timezone in some cases. This ship has sailed, though. If you have any specific suggestions for how PEP 495 features can be better explained in the documentation, I would be glad to hear them. If you are unhappy about some aspects of the design, I am afraid you are a year late to make your point.

1 0

Re: [Datetime-SIG] PEP 495 and the hardest problem in computer science
by Random832 June 29, 2016

June 29, 2016

On Wed, Jun 29, 2016, at 14:56, Alexander Belopolsky wrote: > On Wed, Jun 29, 2016 at 2:35 PM, Random832 <random832(a)fastmail.com> > wrote: > > > Er, I was talking about using it as a naive time using the london > > timezone. > > > > Well, "a naive time using a timezone" is a misnomer. "using the london timezone" was meant to modify "using it", not "naive time". > Note that the result of conversion to UTC is different for t0 and t1 > when they are interpreted as NY times, but the same when they are > interpreted as London time. I'm pretty sure you just proved *my* point - that the flag is meaningless outside of the timezone the time was originally created for [or timezones that happen to have an identical fold] - so maybe I didn't explain it clearly in the first place. It seems to go against the concept of a naive time to contain data that is only relevant to some specific timezone. > I think this all has been explained in the PEP, but discussions like > this may be helpful for writing the documentation.

1 0

Re: [Datetime-SIG] PEP 495 and the hardest problem in computer science
by Alexander Belopolsky June 29, 2016

June 29, 2016

On Wed, Jun 29, 2016 at 2:35 PM, Random832 <random832(a)fastmail.com> wrote: > Er, I was talking about using it as a naive time using the london > timezone. > Well, "a naive time using a timezone" is a misnomer. > Basically, the opposite of what you did: converting that naive > time _from_ London time (you should be able to convert it from any > timezone, after all, since it's naive) _to_ some other timezone. > And you can: >>> New_York = ZoneInfo.fromname('America/New_York') >>> print(t0.replace(tzinfo=New_York).astimezone(timezone.utc)) 2016-11-06 05:30:00+00:00 >>> print(t1.replace(tzinfo=New_York).astimezone(timezone.utc)) 2016-11-06 06:30:00+00:00 >>> print(t0.replace(tzinfo=London).astimezone(timezone.utc)) 2016-11-06 01:30:00+00:00 >>> print(t1.replace(tzinfo=London).astimezone(timezone.utc)) 2016-11-06 01:30:00+00:00 Note that the result of conversion to UTC is different for t0 and t1 when they are interpreted as NY times, but the same when they are interpreted as London time. I think this all has been explained in the PEP, but discussions like this may be helpful for writing the documentation.

1 0

Re: [Datetime-SIG] PEP 495 and the hardest problem in computer science
by Alexander Belopolsky June 29, 2016

June 29, 2016

On Wed, Jun 29, 2016 at 2:40 PM, Guido van Rossum <guido(a)python.org> wrote: > This is a social thread, right? > Right. This mailing list have not seen much traffic lately.

1 0

Re: [Datetime-SIG] PEP 495 and the hardest problem in computer science
by Alexander Belopolsky June 29, 2016

June 29, 2016

On Wed, Jun 29, 2016 at 1:21 PM, Random832 <random832(a)fastmail.com> wrote: > But if I were asking that question in real life, I'd say "Before or > after the time change?", > I disagree. By asking this question, you are introducing an additional knowledge that is completely unnecessary - the moment of "time change." The actual problem is very simple: you have a spelling such as "Nov 6 01:30 AM, New York Time" which happens to be ambiguous. You want to choose between two moments in time that can be described by this phrase. It is quite natural to enumerate them in chronological order and this is exactly what the fold value does. There is no need to explain what happens between these two moments and when. Note that the difference between the two questions is not purely scholastic. In popular system interfaces, finding the moment of "time change" is difficult, so requiring it to be known for the simple task of disambiguating datetime instances in the fold is impractical. > which is understood by all to be an upcoming > time change from DST to non-DST. > No way! It is hard enough to remember Spring-forward/Fall-back. Remembering which one is to and which is from DST is impossible. Pop-quiz: what does S stand in EST? (a) Standard; (b) Summer. And in DST? :-) > A more compelling argument is that it > applies equally to *other* time changes such as a region adopting a > different time zone offset. > Yes, this was an important motivation.

1 0

Re: [Datetime-SIG] PEP 495 and the hardest problem in computer science
by Guido van Rossum June 29, 2016

June 29, 2016

This is a social thread, right? On Wed, Jun 29, 2016 at 11:35 AM, Random832 <random832(a)fastmail.com> wrote: > On Wed, Jun 29, 2016, at 14:19, Alexander Belopolsky wrote: >> I don't think you are correct. With the current Github implementation >> [1] >> of the PEP, I can do the following: >> >> >>> from datetime import * >> >>> from test.datetimetester import ZoneInfo >> >>> London = ZoneInfo.fromname('Europe/London') >> >>> t0 = datetime(2016, 11, 6, 1, 30, fold=0) >> >>> t1 = datetime(2016, 11, 6, 1, 30, fold=1) >> >>> print(t0.astimezone(London)) >> 2016-11-06 05:30:00+00:00 >> >>> print(t1.astimezone(London)) >> 2016-11-06 06:30:00+00:00 >> >> In the snippet above, t0 and t1 are "naive times that care about the >> 'fold'." (My system TZ is US/Eastern.) I am not sure what you mean by >> being portable, but I can convert either of those times to London Time >> using .astimezone() which assumes local timezone for naive instances. > > Er, I was talking about using it as a naive time using the london > timezone. Basically, the opposite of what you did: converting that naive > time _from_ London time (you should be able to convert it from any > timezone, after all, since it's naive) _to_ some other timezone. > _______________________________________________ > 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

Re: [Datetime-SIG] PEP 495 and the hardest problem in computer science
by Random832 June 29, 2016

June 29, 2016

On Wed, Jun 29, 2016, at 14:19, Alexander Belopolsky wrote: > I don't think you are correct. With the current Github implementation > [1] > of the PEP, I can do the following: > > >>> from datetime import * > >>> from test.datetimetester import ZoneInfo > >>> London = ZoneInfo.fromname('Europe/London') > >>> t0 = datetime(2016, 11, 6, 1, 30, fold=0) > >>> t1 = datetime(2016, 11, 6, 1, 30, fold=1) > >>> print(t0.astimezone(London)) > 2016-11-06 05:30:00+00:00 > >>> print(t1.astimezone(London)) > 2016-11-06 06:30:00+00:00 > > In the snippet above, t0 and t1 are "naive times that care about the > 'fold'." (My system TZ is US/Eastern.) I am not sure what you mean by > being portable, but I can convert either of those times to London Time > using .astimezone() which assumes local timezone for naive instances. Er, I was talking about using it as a naive time using the london timezone. Basically, the opposite of what you did: converting that naive time _from_ London time (you should be able to convert it from any timezone, after all, since it's naive) _to_ some other timezone.

1 0

Re: [Datetime-SIG] PEP 495 and the hardest problem in computer science
by Alexander Belopolsky June 29, 2016

June 29, 2016

On Wed, Jun 29, 2016 at 1:21 PM, Random832 <random832(a)fastmail.com> wrote: > > Of course, naive times that care about the 'fold' are only portable to > other timezones that have a fold at the same local time - e.g. among US > timezones (which all have a fold from 2AM to 1AM local) but not EU > timezones (which all transition at the same UTC time and therefore > different local times). I don't think you are correct. With the current Github implementation [1] of the PEP, I can do the following: >>> from datetime import * >>> from test.datetimetester import ZoneInfo >>> London = ZoneInfo.fromname('Europe/London') >>> t0 = datetime(2016, 11, 6, 1, 30, fold=0) >>> t1 = datetime(2016, 11, 6, 1, 30, fold=1) >>> print(t0.astimezone(London)) 2016-11-06 05:30:00+00:00 >>> print(t1.astimezone(London)) 2016-11-06 06:30:00+00:00 In the snippet above, t0 and t1 are "naive times that care about the 'fold'." (My system TZ is US/Eastern.) I am not sure what you mean by being portable, but I can convert either of those times to London Time using .astimezone() which assumes local timezone for naive instances. I am afraid Dan was right when he wrote: "And yet, it will still be confusing, because of how complicated time is in general, and of how humans interpret words." [2] I can only hope that once PEP is implemented, most of the confusion can be resolved by experimentation. [1]: https://github.com/python/cpython/pull/20 [2]: http://blog.danwin.com/pep-495-and-the-hardest-problem-in-computer-science/

1 0

Re: [Datetime-SIG] PEP 495 and the hardest problem in computer science
by Random832 June 29, 2016

June 29, 2016

On Wed, Jun 29, 2016, at 13:11, Alexander Belopolsky wrote: > I came across this blog post [1] by Dan Nguyen and wanted to share it > with > the group. > > [1]: > http://blog.danwin.com/pep-495-and-the-hardest-problem-in-computer-science/ But if I were asking that question in real life, I'd say "Before or after the time change?", which is understood by all to be an upcoming time change from DST to non-DST. A more compelling argument is that it applies equally to *other* time changes such as a region adopting a different time zone offset. But all of this is only necessary because of the peculiar way that Python conceptualizes "naive" local times as independent of any zone. Of course, naive times that care about the 'fold' are only portable to other timezones that have a fold at the same local time - e.g. among US timezones (which all have a fold from 2AM to 1AM local) but not EU timezones (which all transition at the same UTC time and therefore different local times).

1 0

PEP 495 and the hardest problem in computer science
by Alexander Belopolsky June 29, 2016

June 29, 2016

I came across this blog post [1] by Dan Nguyen and wanted to share it with the group. [1]: http://blog.danwin.com/pep-495-and-the-hardest-problem-in-computer-science/

1 0