From alexander.belopolsky at gmail.com Tue Jun 28 21:26:18 2016 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Tue, 28 Jun 2016 21:26:18 -0400 Subject: [Datetime-SIG] PEP 495 implementation In-Reply-To: References: Message-ID: Dear All, I have not received any responses since my first post in this thread in September last year. This time I am adding python-dev to BCC in hopes to reach a larger audience. With the date of the first beta (2016-09-07) fast approaching, I would like to commit PEP 495 implementation hopefully before alpha 3 (2016-07-11). I have a patch published as a pull request [1] against the python/cpython repository on github. If anyone still prefers the bug tracker workflow, I can publish it as a patch for issue #24773 [2] as well. Please also see my post from March below. Since that post, I have implemented a -utzdata option to the regression test, so now the long exhaustive test only runs when you do python -mtest -utzdata. Note that this test currently fails on a couple exotic timezones such as Asia/Riyadh87, but it is likely to be an issue with the timezone database rather than python code. I still don't have access to a Windows development box and I know that the current implementation will not work there because I use localtime_r. I need help/advise on this front. I have not started updating the documentation, so the PEP text [3] should serve as the documentation for now. I will try to get the documentation patch ready before the beta, but I don't want to delay checking in the code. On Mon, Mar 21, 2016 at 10:34 PM, Alexander Belopolsky < alexander.belopolsky at gmail.com> wrote: > > Dear All, > > I am getting close to completing PEP 495 implementation, but I need someone to help me with a port to Windows. One of the major obstacles is that my implementation relies heavily on the POSIX localtime_r function which apparently is not available on Windows. > > I would also appreciate help from a unittest expert to improve test_datetime. One of the pressing tasks is to make ZoneInfoCompleteTest optional because it takes several minutes to complete. > > I am maintaining the patch as a pull request [1] against the python/cpython repository on github. Code reviews are most welcome. > > [1]: https://github.com/python/cpython/pull/20 [2]: http://bugs.python.org/issue24773 [3]: https://www.python.org/dev/peps/pep-0495 -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.belopolsky at gmail.com Wed Jun 29 13:11:03 2016 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Wed, 29 Jun 2016 13:11:03 -0400 Subject: [Datetime-SIG] PEP 495 and the hardest problem in computer science Message-ID: 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From random832 at fastmail.com Wed Jun 29 13:21:41 2016 From: random832 at fastmail.com (Random832) Date: Wed, 29 Jun 2016 13:21:41 -0400 Subject: [Datetime-SIG] PEP 495 and the hardest problem in computer science In-Reply-To: References: Message-ID: <1467220901.2854596.652200657.10091706@webmail.messagingengine.com> 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). From alexander.belopolsky at gmail.com Wed Jun 29 14:19:29 2016 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Wed, 29 Jun 2016 14:19:29 -0400 Subject: [Datetime-SIG] PEP 495 and the hardest problem in computer science In-Reply-To: <1467220901.2854596.652200657.10091706@webmail.messagingengine.com> References: <1467220901.2854596.652200657.10091706@webmail.messagingengine.com> Message-ID: On Wed, Jun 29, 2016 at 1:21 PM, Random832 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From random832 at fastmail.com Wed Jun 29 14:35:36 2016 From: random832 at fastmail.com (Random832) Date: Wed, 29 Jun 2016 14:35:36 -0400 Subject: [Datetime-SIG] PEP 495 and the hardest problem in computer science In-Reply-To: References: <1467220901.2854596.652200657.10091706@webmail.messagingengine.com> Message-ID: <1467225336.2869465.652274297.1B0208DF@webmail.messagingengine.com> 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. From guido at python.org Wed Jun 29 14:40:33 2016 From: guido at python.org (Guido van Rossum) Date: Wed, 29 Jun 2016 11:40:33 -0700 Subject: [Datetime-SIG] PEP 495 and the hardest problem in computer science In-Reply-To: <1467225336.2869465.652274297.1B0208DF@webmail.messagingengine.com> References: <1467220901.2854596.652200657.10091706@webmail.messagingengine.com> <1467225336.2869465.652274297.1B0208DF@webmail.messagingengine.com> Message-ID: This is a social thread, right? On Wed, Jun 29, 2016 at 11:35 AM, Random832 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 at 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) From alexander.belopolsky at gmail.com Wed Jun 29 14:42:41 2016 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Wed, 29 Jun 2016 14:42:41 -0400 Subject: [Datetime-SIG] PEP 495 and the hardest problem in computer science In-Reply-To: <1467220901.2854596.652200657.10091706@webmail.messagingengine.com> References: <1467220901.2854596.652200657.10091706@webmail.messagingengine.com> Message-ID: On Wed, Jun 29, 2016 at 1:21 PM, Random832 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.belopolsky at gmail.com Wed Jun 29 14:44:33 2016 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Wed, 29 Jun 2016 14:44:33 -0400 Subject: [Datetime-SIG] PEP 495 and the hardest problem in computer science In-Reply-To: References: <1467220901.2854596.652200657.10091706@webmail.messagingengine.com> <1467225336.2869465.652274297.1B0208DF@webmail.messagingengine.com> Message-ID: On Wed, Jun 29, 2016 at 2:40 PM, Guido van Rossum wrote: > This is a social thread, right? > Right. This mailing list have not seen much traffic lately. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.belopolsky at gmail.com Wed Jun 29 14:56:25 2016 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Wed, 29 Jun 2016 14:56:25 -0400 Subject: [Datetime-SIG] PEP 495 and the hardest problem in computer science In-Reply-To: <1467225336.2869465.652274297.1B0208DF@webmail.messagingengine.com> References: <1467220901.2854596.652200657.10091706@webmail.messagingengine.com> <1467225336.2869465.652274297.1B0208DF@webmail.messagingengine.com> Message-ID: On Wed, Jun 29, 2016 at 2:35 PM, Random832 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From random832 at fastmail.com Wed Jun 29 16:05:47 2016 From: random832 at fastmail.com (Random832) Date: Wed, 29 Jun 2016 16:05:47 -0400 Subject: [Datetime-SIG] PEP 495 and the hardest problem in computer science In-Reply-To: References: <1467220901.2854596.652200657.10091706@webmail.messagingengine.com> <1467225336.2869465.652274297.1B0208DF@webmail.messagingengine.com> Message-ID: <1467230747.2888910.652360049.1F10F5E1@webmail.messagingengine.com> On Wed, Jun 29, 2016, at 14:56, Alexander Belopolsky wrote: > On Wed, Jun 29, 2016 at 2:35 PM, Random832 > 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. From alexander.belopolsky at gmail.com Wed Jun 29 16:51:56 2016 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Wed, 29 Jun 2016 16:51:56 -0400 Subject: [Datetime-SIG] PEP 495 and the hardest problem in computer science In-Reply-To: <1467230747.2888910.652360049.1F10F5E1@webmail.messagingengine.com> References: <1467220901.2854596.652200657.10091706@webmail.messagingengine.com> <1467225336.2869465.652274297.1B0208DF@webmail.messagingengine.com> <1467230747.2888910.652360049.1F10F5E1@webmail.messagingengine.com> Message-ID: On Wed, Jun 29, 2016 at 4:05 PM, Random832 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: