Mailman 3 September 2015 - Datetime-SIG

Re: [Datetime-SIG] Making tm_gmtoff and tm_zone available on all platforms
by Alexander Belopolsky Sept. 30, 2015

Sept. 30, 2015

On Tue, Sep 29, 2015 at 5:03 PM, Guido van Rossum <guido(a)python.org> wrote: > OK, I think this is fine then. Implementation will be tracked at <http://bugs.python.org/issue25283>.

1 0

Re: [Datetime-SIG] Making tm_gmtoff and tm_zone available on all platforms
by Guido van Rossum Sept. 29, 2015

Sept. 29, 2015

OK, I think this is fine then. On Mon, Sep 28, 2015 at 8:29 PM, Alexander Belopolsky < alexander.belopolsky(a)gmail.com> wrote: > > On Mon, Sep 28, 2015 at 11:04 PM, Guido van Rossum <guido(a)python.org> > wrote: > > > > I had been wondering about that myself. But your implementation proposal > sounds kind of expensive, doesn't it? > > > It could be with a naive implementation that would simply fill additional > fields in the existing time.struct_time object, but we can also modify the > struct_time class to compute the additional attributes only when they are > requested. (I believe struct_time is currently implemented as > PyStructSequence, so we will probably need to subclass that somehow.) > > On the other hand, I would start with a naive implementation and worry > about the optimizations later. As far as I know, the POSIX layer on > Windows (which is the main platform that will be affected) is already very > slow, so the price of cross-platform portability may be within user > expectations in this case. > -- --Guido van Rossum (python.org/~guido)

1 0

PEP 495 implementation
by Alexander Belopolsky Sept. 29, 2015

Sept. 29, 2015

I have completed a pure python implementation of PEP 495 and the patch is ready for review. [1] If you prefer the Github interface, please review the pull request from my cpython clone. [2] Finally, please add yourself as "nosy" to issue #24773 [3] if you would like to follow future developments. [1]: http://bugs.python.org/review/24773/#ps15654 [2]: https://github.com/python/cpython/pull/20 [3]: http://bugs.python.org/issue24773

1 0

Re: [Datetime-SIG] Making tm_gmtoff and tm_zone available on all platforms
by Alexander Belopolsky Sept. 29, 2015

Sept. 29, 2015

On Mon, Sep 28, 2015 at 11:04 PM, Guido van Rossum <guido(a)python.org> wrote: > > I had been wondering about that myself. But your implementation proposal sounds kind of expensive, doesn't it? It could be with a naive implementation that would simply fill additional fields in the existing time.struct_time object, but we can also modify the struct_time class to compute the additional attributes only when they are requested. (I believe struct_time is currently implemented as PyStructSequence, so we will probably need to subclass that somehow.) On the other hand, I would start with a naive implementation and worry about the optimizations later. As far as I know, the POSIX layer on Windows (which is the main platform that will be affected) is already very slow, so the price of cross-platform portability may be within user expectations in this case.

1 0

Re: [Datetime-SIG] Making tm_gmtoff and tm_zone available on all platforms
by Guido van Rossum Sept. 29, 2015

Sept. 29, 2015

I had been wondering about that myself. But your implementation proposal sounds kind of expensive, doesn't it? On Mon, Sep 28, 2015 at 6:21 PM, Alexander Belopolsky < alexander.belopolsky(a)gmail.com> wrote: > Most UNIX platforms extend struct tm to include tm_gmtoff and tm_zone > fields that contain the current UTC offset in seconds and the zone > abbreviation. > > Python has been making these fields available as attributes of > time.struct_time [1] since version 3.3, but only on platforms that support > them in the C library. > > >>> import time > >>> t = time.localtime() > >>> t.tm_gmtoff > -14400 > >>> t.tm_zone > 'EDT' > > I propose that we make these attributes available on all platforms by > computing their values when they are not available in struct tm. > > The tm_gmtoff value is easy to compute by comparing localtime() to > gmtime(): > > >>> u = time.gmtime(time.mktime(t)) > >>> from calendar import timegm > >>> timegm(t) - timegm(u) > -14400 > > and tm_zone can be computed by calling strftime() with a '%Z' directive. > > >>> time.strftime('%Z', t) > 'EDT' > > What does the group think? > > [1]: https://docs.python.org/3/library/time.html#time.struct_time > > _______________________________________________ > 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

Making tm_gmtoff and tm_zone available on all platforms
by Alexander Belopolsky Sept. 29, 2015

Sept. 29, 2015

Most UNIX platforms extend struct tm to include tm_gmtoff and tm_zone fields that contain the current UTC offset in seconds and the zone abbreviation. Python has been making these fields available as attributes of time.struct_time [1] since version 3.3, but only on platforms that support them in the C library. >>> import time >>> t = time.localtime() >>> t.tm_gmtoff -14400 >>> t.tm_zone 'EDT' I propose that we make these attributes available on all platforms by computing their values when they are not available in struct tm. The tm_gmtoff value is easy to compute by comparing localtime() to gmtime(): >>> u = time.gmtime(time.mktime(t)) >>> from calendar import timegm >>> timegm(t) - timegm(u) -14400 and tm_zone can be computed by calling strftime() with a '%Z' directive. >>> time.strftime('%Z', t) 'EDT' What does the group think? [1]: https://docs.python.org/3/library/time.html#time.struct_time

1 0

Re: [Datetime-SIG] IANA TZ database statistics
by Alexander Belopolsky Sept. 26, 2015

Sept. 26, 2015

On Fri, Sep 25, 2015 at 11:36 PM, Tim Peters <tim.peters(a)gmail.com> wrote: > Well, the Tallinn source rules I see include: > > 2:00 EU EE%sT 1999 Nov 1 > 2:00 - EET 2002 Feb 21 > That's a bug that has been fixed in 2015f. See < http://mm.icann.org/pipermail/tz/2015-June/022309.html> for details.

1 0

Re: [Datetime-SIG] IANA TZ database statistics
by Alexander Belopolsky Sept. 26, 2015

Sept. 26, 2015

On Fri, Sep 25, 2015 at 11:36 PM, Tim Peters <tim.peters(a)gmail.com> wrote: > > [Alex] > > Yes. That's the condition I've been talking for months about. > > ? "if we (generously) allow utcoffset to vary from -24h to +24h, then a "sane" zone can be defined as the one where utcoffset changes at most once in any 48 hour period." https://mail.python.org/pipermail/python-dev/2015-April/139171.html

1 0

Re: [Datetime-SIG] IANA TZ database statistics
by Tim Peters Sept. 26, 2015

Sept. 26, 2015

[Tim] >> So it seems a sufficient condition is that there's at most one UTC >> offset change in the last 24 hours. [Alex] > Yes. That's the condition I've been talking for months about. ? > If you have a chance, please take a look at > > https://github.com/abalkin/cpython/commit/d146830e70a1fda22380c5ba0d9592c16… > > It fails on Europe/Tallinn which seems to have transitions separated by 22 > hours with the *same* utcoffset. > > I don't understand why zic would ever produce something like this. Well, the Tallinn source rules I see include: 2:00 EU EE%sT 1999 Nov 1 2:00 - EET 2002 Feb 21 That is, they decided to stop messing with DST at all effective the start of November, 1999. But until then, they were following "EU" daylight rules. Which ends DST on the last Sunday of October, which in 1999 happened to be Oct 31. So the first switch to EET local Sunday morning was due to EU daylight time ending, and then the second "switch" to EET at local midnight was due to Tallinn opting out of DST rules altogether. Which didn't change the zone name, DST status, or UTC offset. The output of zic doesn't appear nearly well defined enough to say whether that's "a bug" or "a feature", though :-(

1 0

Re: [Datetime-SIG] IANA TZ database statistics
by Alexander Belopolsky Sept. 26, 2015

Sept. 26, 2015

On Fri, Sep 25, 2015 at 10:28 PM, Tim Peters <tim.peters(a)gmail.com> wrote: > So it seems a sufficient condition is that there's at most one UTC > offset change in the last 24 hours. > Apparently [1] we are not alone in wanting this condition. [1]: http://mm.icann.org/pipermail/tz/2015-June/022309.html

1 0