This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Implement PEP 495 (Local Time Disambiguation)
Type: enhancement Stage: resolved
Components: Extension Modules, Library (Lib) Versions: Python 3.6
process
Status: closed Resolution: fixed
Dependencies: Superseder: Document PEP 495 (Local Time Disambiguation) features
View: 27595
Assigned To: belopolsky Nosy List: akira, belopolsky, koobs, martin.panter, python-dev, stub, tim.peters, vstinner
Priority: normal Keywords: patch

Created on 2015-08-01 19:17 by belopolsky, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
ltdf.patch belopolsky, 2015-08-01 19:17 Initial pure python implementation
ltdf-2.patch belopolsky, 2015-08-01 21:49 review
issue24773-s3.diff belopolsky, 2015-09-29 03:54 review
issue24773-s3-2.diff belopolsky, 2016-07-16 17:17 review
issue24773-s3-3.diff belopolsky, 2016-07-18 16:53 review
issue24773-s3-4.diff belopolsky, 2016-07-18 23:54 review
issue24773-final.diff belopolsky, 2016-07-22 22:44 review
koobs-freebsd-current-usr-share-zoneinfo.txt koobs, 2016-07-24 04:13
Repositories containing patches
https://github.com/abalkin/cpython.git#issue24773-s3
Messages (48)
msg247819 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2015-08-01 19:17
Adds a boolean member to the instances of ``datetime.time``
and ``datetime.datetime`` classes that can be used to differentiate
between two moments in time for which local times are the same.

See Datetime-SIG "Local time disambiguation proposal" discussion [1] for more details.

[1]: https://mail.python.org/pipermail/datetime-sig/2015-July/000105.html
msg247831 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2015-08-01 21:42
Something went wrong in my hg clone and Rietveld did not like my patch.  I moved my development branch to github:

https://github.com/abalkin/cpython/tree/ltdf

Please feel free to leave your comments there.
msg251811 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2015-09-29 01:53
Changing the title to reference PEP 495.
msg270574 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2016-07-16 17:17
Submitting the latest Github snapshot as a patch against master for review.  See issue24773-s3-2.diff.
msg270776 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2016-07-18 16:53
Naoki, thanks for the review.  I addressed your comments in 

https://github.com/abalkin/cpython/commit/a61a25d2dd04336361b2ea676c80afdb2639f579

Attached patch, issue24773-s3-3.diff, incorporates your comments and a few other fixes.  See github for the full history.
msg270797 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2016-07-18 23:54
The new patch passes test_datetime on Windows.  This was the last stumbling block for me to commit this patch.  Unless anyone would ask for more time to review, I plan to commit later this week.
msg271039 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2016-07-22 22:44
I am posting the final version of the patch complete with the NEWS entry.  Compared with the previous patch, issue24773-final.diff contains a fix for a reference leak.

I would like to use this opportunity to thank Zachary Ware for providing a Windows VM with a complete Python development setup, as well as everyone who participated in PEP 495 discussions and code reviews.
msg271040 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2016-07-22 22:47
New changeset 7c0917670ab8 by Alexander Belopolsky in branch 'default':
Closes issue #24773: Implement PEP 495 (Local Time Disambiguation).
https://hg.python.org/cpython/rev/7c0917670ab8
msg271048 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2016-07-23 03:09
This upset the buildbots:

http://buildbot.python.org/all/builders/PPC64%20Fedora%203.x/builds/1259/steps/test/logs/stdio
======================================================================
FAIL: test_all (test.datetimetester.ZoneInfoCompleteTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64/build/Lib/test/datetimetester.py", line 4784, in test_all
    self.assertTrue(result.wasSuccessful(), name + ' ' + suffix)
AssertionError: False is not true : Africa/El_Aaiun system_transitions
msg271063 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2016-07-23 06:48
FYI, other failures that may be different problems:

http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.x/builds/4930/steps/test/logs/stdio
Timeout (0:15:00)!
Thread 0x00007fff71296cc0 (most recent call first):
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/datetime.py", line 447 in __new__
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/datetime.py", line 1444 in _fromtimestamp
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/datetime.py", line 1467 in utcfromtimestamp
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/datetimetester.py", line 4637 in transitions
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/datetimetester.py", line 4659 in folds
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/datetimetester.py", line 4688 in test_folds
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/case.py", line 600 in run
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/datetimetester.py", line 4783 in test_all

http://buildbot.python.org/all/builders/AMD64%20OpenIndiana%203.x/builds/11008/steps/test/logs/stdio
======================================================================
ERROR: test_folds (test.datetimetester.IranTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/datetimetester.py", line 4680, in setUp
    self.tz = ZoneInfo.fromname(self.zonename)
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/datetimetester.py", line 4514, in fromname
    with open(path, 'rb') as f:
FileNotFoundError: [Errno 2] No such file or directory: '/usr/share/zoneinfo/Iran'

http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.x/builds/13492/steps/test/logs/stdio
(I also get this OverflowError for a 32-bit ABI build)
======================================================================
ERROR: test_timestamp_naive (test.datetimetester.TestSubclassDateTime)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/support/__init__.py", line 1563, in inner
    return func(*args, **kwds)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/datetimetester.py", line 1931, in test_timestamp_naive
    self.assertEqual(self.theclass.fromtimestamp(s), t)
OverflowError: timestamp out of range for platform time_t
msg271073 - (view) Author: Kubilay Kocak (koobs) (Python triager) Date: 2016-07-23 11:24
Also failing on all freebsd buildbots, all tests failing with:

FileNotFoundError: [Errno 2] No such file or directory: '/usr/share/zoneinfo/Iran'
msg271081 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2016-07-23 14:57
Does anyone know whether zoneinfo is installed on FreeBSD buildbot?  If it is, at which path?

> On Jul 23, 2016, at 7:24 AM, koobs <report@bugs.python.org> wrote:
> 
> 
> koobs added the comment:
> 
> Also failing on all freebsd buildbots, all tests failing with:
> 
> FileNotFoundError: [Errno 2] No such file or directory: '/usr/share/zoneinfo/Iran'
> 
> ----------
> nosy: +koobs
> resolution: fixed -> 
> 
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue24773>
> _______________________________________
msg271086 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2016-07-23 15:17
New changeset e72aab080165 by Alexander Belopolsky in branch 'default':
Issue 24773: Make zoneinfo tests more robust.
https://hg.python.org/cpython/rev/e72aab080165
msg271087 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2016-07-23 15:36
> AssertionError: False is not true : Africa/El_Aaiun system_transitions

This may be an indication of misconfigured zoneinfo on the buildbot.  What system_transitions test does is compare the results obtained from the system timezone computations to the same computations using an explicitly loaded timezone.  This may fail if /usr/share/zoneinfo exists, but the system is using a different database.

Is there a way to troubleshoot the buildbot short of trying a series of hg commits?
msg271127 - (view) Author: Kubilay Kocak (koobs) (Python triager) Date: 2016-07-24 04:13
I can help providing information on the koobs-* freebsd buildbots (I run them). 

In a default installation, the timezone entries are available in /usr/share/zoneinfo (see attachment for contents)

Iran is not in the root directory, 'Tehran' is in Asia/ subdirectory

tzsetup man page: https://www.freebsd.org/cgi/man.cgi?query=tzsetup&sektion=8

The misc/zoneinfo port/package [1] can be installed which overwrites entries in the above location.

The files this port/package installs are in the pkg-plist file:

https://svnweb.freebsd.org/ports/head/misc/zoneinfo/pkg-plist?view=log

There doesn't appear to be an 'Iran' entry in the root of this port/package either, so my guess is its a distribution specific location

[1] https://svnweb.freebsd.org/ports/head/misc/zoneinfo/

Beyond the above, tests should not fail (but skip) if the resources it requires are not available, so the change in e72aab080165 is welcome
msg271128 - (view) Author: Kubilay Kocak (koobs) (Python triager) Date: 2016-07-24 04:18
See Also:

non standard (standard?) timezones.
https://lists.freebsd.org/pipermail/freebsd-hackers/2015-May/047765.html

I don't know to what extent these links are considered standard, but I'll talk to Julian about whether we can get these links installed in FreeBSD base (and the zoneinfo port/package). having said that, even if they can be/are added, the tests should still not expect them (blindly) to be available.
msg271147 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2016-07-24 12:29
FWIW I can produce two of these failures locally: the time_t OverflowError, and the test_all() system_transitions one. Let me know if you want any more info. In my case the message for the test_all() failure is “posix/Africa/Casablanca system_transitions”. I am on 64-bit Arch Linux, but Python is currently compiled for the 32-bit ABI.

$ pacman -Qo /usr/share/zoneinfo/posix/Africa/Casablanca
/usr/share/zoneinfo/posix/Africa/Casablanca is owned by tzdata 2013h-1
msg271166 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2016-07-24 16:07
> the time_t OverflowError

The issue here is that for a large date, dt.timestamp() returns a float large enough to cause overflow in fromtimestamp.

> Let me know if you want any more info.

Can you figure out what date causes this (0002-01-01 or 9998-12-12 or both)?  What value is returned by dt.timestamp()?  Does pure python implementation behave the same as C? (SEt sys.modules['_datetime'] to None before importing datetime to get a pure python implementation.)

> In my case the message for the test_all() failure is “posix/Africa/Casablanca system_transitions”.

Do you get this failure only on a 32-bit interpreter?  Please add

class CasablancaTest(ZoneInfoTest):
    zonename = 'Africa/Casablanca'

to datetimetester.py and run python -mtest -v test_datetime.
msg271167 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2016-07-24 16:18
Looking at the stable buildbots.

http://buildbot.python.org/all/waterfall?category=3.x.stable

AMD64 OpenIndiana 3.x - unrelated failures
AMD64 Snow Leop 3.x - crash in test_all / system_transitions
PPC64 Fedora 3.x - fail in test_all Africa/El_Aaiun system_transitions
x86 Ubuntu Shared 3.x - two failures: time_t overflow and Africa/El_Aaiun
msg271178 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2016-07-24 18:41
New changeset ae19ea7c36e6 by Alexander Belopolsky in branch 'default':
Issue #24773: Made ZoneInfoCompleteTest a TestSuit.
https://hg.python.org/cpython/rev/ae19ea7c36e6
msg271192 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2016-07-25 00:36
New changeset dca143512f6e by Alexander Belopolsky in branch 'default':
Issue 24773: Make zoneinfo tests more robust. (reapply)
https://hg.python.org/cpython/rev/dca143512f6e
msg271229 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2016-07-25 04:58
Without blocking the C implementation _datetime, I get both extremes causing OverflowError:

>>> import datetime, time, os
>>> os.environ["TZ"] = "EST+05EDT,M3.2.0,M11.1.0"
>>> time.tzset()
>>> t = datetime.datetime(2,1,1)
>>> s = t.timestamp()
>>> s
-122233584944.0
>>> datetime.datetime.fromtimestamp(s)
OverflowError: timestamp out of range for platform time_t
>>> t = datetime.datetime(9998,12,12)
>>> s = t.timestamp()
>>> s
760175195728.0
>>> datetime.datetime.fromtimestamp(s)
OverflowError: timestamp out of range for platform time_t

When I repeated the test with sys["_datetime"] = None, both t.timestamp() calls raised OverflowError, which I assume is expected.
msg271233 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2016-07-25 05:09
I _think_ the system_transitions failure only happens for 32 bit (have to test more to be sure). (My 32-bit environment is lacking many libraries compared to main 64-bit environment, but still uses the same filesystem etc.) First system_transitions failure with today’s new code:

FAIL: test_system_transitions (test.datetimetester.ZoneInfoTest[posix/Africa/Casablanca])
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/media/disk/home/proj/python/cpython/Lib/test/datetimetester.py", line 4760, in test_system_transitions
    self.assertEquivDatetimes(sdt, tzdt)
  File "/media/disk/home/proj/python/cpython/Lib/test/datetimetester.py", line 4687, in assertEquivDatetimes
    (b.replace(tzinfo=None), b.fold, id(b.tzinfo)))
AssertionError: Tuples differ: (datetime.datetime(2037, 10, 11, 3, 0), 0, 140273296) != (datetime.datetime(2037, 10, 11, 2, 0, fold=1), 1, 140273296)

First differing element 0:
datetime.datetime(2037, 10, 11, 3, 0)
datetime.datetime(2037, 10, 11, 2, 0, fold=1)

- (datetime.datetime(2037, 10, 11, 3, 0), 0, 140273296)
?                                  ^      ^

+ (datetime.datetime(2037, 10, 11, 2, 0, fold=1), 1, 140273296)
?                                  ^   ++++++++   ^

Your CasablancaTest gave the same failure:
======================================================================
FAIL: test_system_transitions (test.datetimetester.CasablancaTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/media/disk/home/proj/python/cpython/Lib/test/datetimetester.py", line 4760, in test_system_transitions
    self.assertEquivDatetimes(sdt, tzdt)
  File "/media/disk/home/proj/python/cpython/Lib/test/datetimetester.py", line 4687, in assertEquivDatetimes
    (b.replace(tzinfo=None), b.fold, id(b.tzinfo)))
AssertionError: Tuples differ: (datetime.datetime(2037, 10, 11, 3, 0), 0, 140273296) != (datetime.datetime(2037, 10, 11, 2, 0, fold=1), 1, 140273296)

First differing element 0:
datetime.datetime(2037, 10, 11, 3, 0)
datetime.datetime(2037, 10, 11, 2, 0, fold=1)

- (datetime.datetime(2037, 10, 11, 3, 0), 0, 140273296)
?                                  ^      ^

+ (datetime.datetime(2037, 10, 11, 2, 0, fold=1), 1, 140273296)
?                                  ^   ++++++++   ^
msg271234 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2016-07-25 05:12
That's very helpful.  It looks like on a Mac 32-bit build has 64-bit time_t.  I'll build a 32-bit Python on Linux tomorrow and try to get to the bottom of this.
msg271239 - (view) Author: Kubilay Kocak (koobs) (Python triager) Date: 2016-07-25 06:47
koobs-freebsd-* 3.x builds are now passing, but I'd like to make an additional (trivial) proposal, and that is:

If the tests that were previously failling, aren't *specifically* testing for 'backward compatible' timezone definitions, that the tests that currently use $ROOT/Iran timezone file, instead use a timezone file that is *not* contained within the 'backwards' (backwards compatible) timezone file in the zoneinfo distribution, which may or may not be installed in various environments.

For example, the tests could instead use Asia/Tehran
msg271300 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2016-07-25 17:54
New changeset 8cc06070e98b by Alexander Belopolsky in branch 'default':
Issue 24773: Added a time_t overflow check.
https://hg.python.org/cpython/rev/8cc06070e98b
msg271313 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2016-07-26 01:01
The remaining failures all seems to be related to the Morocco rules: both Africa/El_Aaiun [1] and Africa/Casablanca [2] use those rules.

The affected date is October 4, 2037, for which Morocco has a special rule. [3]


It looks like the problem is with the system date/time library.  The 2037 transition is specified in the tzfile as POSIX time 2138234400 and system date utility produced a value different from that of IANA's date [4]:

$ TZ=/usr/share/zoneinfo/Africa/El_Aaiun date -d @2138234400
Sun Oct  4 03:00:00 WEST 2037
$ TZ=/usr/share/zoneinfo/Africa/El_Aaiun ./date -r 2138234400
Sun Oct  4 02:00:00 WET 2037

[1]: https://github.com/eggert/tz/blob/2016f/africa#L917
[2]: https://github.com/eggert/tz/blob/2016f/africa#L901
[3]: https://github.com/eggert/tz/blob/2016f/africa#L898
[4]: https://github.com/eggert/tz/blob/2016f/date.c
msg271315 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2016-07-26 01:14
Could our Morocco issue be similar to Fiji issue?

https://github.com/eggert/tz/commit/6d00980f1ff2ac665f3de027c79faacf4f26d1b0
msg271318 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2016-07-26 02:29
Just confirming that my Casablanca failure is restricted to the 32-bit build, though I think you already figured this out.
msg271393 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2016-07-26 16:23
New changeset 95df96aa2f5a by Alexander Belopolsky in branch 'default':
Issue #24773: Fixed tests failures on systems with 32-bit time_t.
https://hg.python.org/cpython/rev/95df96aa2f5a
msg271396 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2016-07-26 17:13
It looks like PPC64 Fedora 3.x builder [1] also has a problem with a transition in 2037.

[1]: http://buildbot.python.org/all/builders/PPC64%20Fedora%203.x
msg271413 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2016-07-26 21:15
It looks like th Morocco issue has been reported to CentOS recently but they kicked it upstream. 

https://sourceware.org/ml/libc-help/2016-04/msg00000.html
msg271414 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2016-07-26 21:21
Also reported for Ubuntu:

https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1587128
msg271473 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2016-07-27 21:26
It looks like Ruby folks encountered the Morocco issue [1] before us.  They closed the issue on their bug tracker blaming glibc.  This tells us, I guess, that we should skip this transition on the affected systems.  Unfortunately, it is not just 32-bit time_t systems - I was able to reproduce the problem on 64-bit Fedora 22.

If no one suggests a better way, I will just skip year 2037 transitions unconditionally.  


[1]: https://github.com/tzinfo/tzinfo-data/issues/10
msg271559 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2016-07-28 15:29
It looks like the tzdata folks have agreed [1] that there is a problem with the Morocco rules in the Africa file and will likely fix it in the next release.

This is an interesting situation where a bug in tzcode masks a bug in tzdata while glibc implements the documented behavior faithfully but as a result suffers from the data bug.

I will wait for the conclusion of the discussion on the TZ list because there is a chance that we should fix the ZoneInfo logic to match glibc. 

[1]: http://mm.icann.org/pipermail/tz/2016-July/023896.html
msg271695 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2016-07-30 15:37
> I don't know to what extent these links are considered standard (koobs)

The links like Iran are non-standard.  they are specified in the "backward" file in the IANA tzdata distribution which has the following preamble:

# This file provides links between current names for time zones
# and their old names.  Many names changed in late 1993.

I'll change "Iran" to "Asia/Tehran" in the test.

$ grep Iran Work/tz/backward
Link	Asia/Tehran		Iran
msg271696 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2016-07-30 15:41
New changeset eed3a5b9239f by Alexander Belopolsky in branch 'default':
Issue 24773: Use the standard Asia/Tehran name in the Iran test.
https://hg.python.org/cpython/rev/eed3a5b9239f
msg271734 - (view) Author: Kubilay Kocak (koobs) (Python triager) Date: 2016-07-31 10:53
Thank you Alexander, consider me satisfied :)
msg272398 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2016-08-11 04:05
Any news on the remaining failures for year 2037?

What about the buildbots that time out? Can the size of the tests be reduced, or perhaps should the buildbots be updated to extend the timeout?
msg272448 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2016-08-11 14:34
> Any news on the remaining failures for year 2037?

Yes, the problem was tracked to a bug [1] in zic.  If the buildbots get regular updates, the problem will go away with the next tzdata release.  Meanwhile, I'll try to figure out a way to suppress the error.

[1]: https://github.com/eggert/tz/commit/081c50f30308b589e7e296f485135d03cf046cb1
msg272449 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2016-08-11 14:39
> Can the size of the tests be reduced, [...]?

Yes, the long test walks the zoneinfo tree and runs on every tzfile including the aliases.  I am going to change that to parsing the zone.tab file for the list of zone names.  This should shorten the time at least 2x.
msg272452 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2016-08-11 15:01
New changeset 05120447f2c6 by Alexander Belopolsky in branch 'default':
Issue #24773: Fix and speed-up ZoneInfoCompleteTest.
https://hg.python.org/cpython/rev/05120447f2c6
msg272489 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2016-08-12 02:01
Both parts of your commit seem to have helped. However I found two failures still happening, and one new failure:

1. Casablanca and El_Aaiun still failing since the original commit:
http://buildbot.python.org/all/builders/PPC64%20Fedora%203.x/builds/1318/steps/test/logs/stdio
======================================================================
FAIL: test_system_transitions (test.datetimetester.ZoneInfoTest[Africa/El_Aaiun])
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64/build/Lib/test/datetimetester.py", line 4781, in test_system_transitions
    self.assertEquivDatetimes(sdt, tzdt)
  File "/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64/build/Lib/test/datetimetester.py", line 4706, in assertEquivDatetimes
    (b.replace(tzinfo=None), b.fold, id(b.tzinfo)))
AssertionError: Tuples differ: (datetime.datetime(2037, 10, 10, 3, 0), 0, 271733936) != (datetime.datetime(2037, 10, 10, 2, 0, fold=1), 1, 271733936)

First differing element 0:
datetime.datetime(2037, 10, 10, 3, 0)
datetime.datetime(2037, 10, 10, 2, 0, fold=1)

- (datetime.datetime(2037, 10, 10, 3, 0), 0, 271733936)
?                                  ^      ^

+ (datetime.datetime(2037, 10, 10, 2, 0, fold=1), 1, 271733936)
?                                  ^   ++++++++   ^

2. The two Gentoo buildbots started failing at some point _after_ the original commit. The corresponding commit (b04560c3ce69) is not relevant to datetime.
http://buildbot.python.org/all/builders/x86%20Gentoo%20Non-Debug%20with%20X%203.x/builds/1219/steps/test/logs/stdio
======================================================================
ERROR: test_folds (test.datetimetester.ZoneInfoTest[Asia/Qyzylorda])
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/buildbot/buildarea/3.x.ware-gentoo-x86/build/Lib/test/datetimetester.py", line 4694, in setUp
    self.tz = ZoneInfo.fromname(self.zonename)
  File "/buildbot/buildarea/3.x.ware-gentoo-x86/build/Lib/test/datetimetester.py", line 4527, in fromname
    return cls.fromfile(f)
  File "/buildbot/buildarea/3.x.ware-gentoo-x86/build/Lib/test/datetimetester.py", line 4519, in fromfile
    self = cls(ut, ti)
  File "/buildbot/buildarea/3.x.ware-gentoo-x86/build/Lib/test/datetimetester.py", line 4472, in __init__
    self.lt = self.invert(ut, ti)
  File "/buildbot/buildarea/3.x.ware-gentoo-x86/build/Lib/test/datetimetester.py", line 4482, in invert
    lt[0][i] += ti[i-1][0] // SEC
OverflowError: Python int too large to convert to C long

3. It looks like removing the sizeof_time_t skip re-introduced a year 2037 failure for Cairo, although many other tests (e.g. New_York) that were skipped are now passing:
http://buildbot.python.org/all/builders/x86%20Gentoo%20Non-Debug%20with%20X%203.x/builds/1228/steps/test/logs/stdio
======================================================================
FAIL: test_system_transitions (test.datetimetester.ZoneInfoTest[Africa/Cairo])
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/buildbot/buildarea/3.x.ware-gentoo-x86/build/Lib/test/datetimetester.py", line 4781, in test_system_transitions
    self.assertEquivDatetimes(sdt, tzdt)
  File "/buildbot/buildarea/3.x.ware-gentoo-x86/build/Lib/test/datetimetester.py", line 4706, in assertEquivDatetimes
    (b.replace(tzinfo=None), b.fold, id(b.tzinfo)))
AssertionError: Tuples differ: (datetime.datetime(2037, 10, 9, 0, 0), 0, 137328448) != (datetime.datetime(2037, 10, 8, 23, 0, fold=1), 1, 137328448)

First differing element 0:
datetime.datetime(2037, 10, 9, 0, 0)
datetime.datetime(2037, 10, 8, 23, 0, fold=1)

- (datetime.datetime(2037, 10, 9, 0, 0), 0, 137328448)
?                              ^     ^   ^

+ (datetime.datetime(2037, 10, 8, 23, 0, fold=1), 1, 137328448)
?                              ^ ++++    ^^^^^^   ^
msg272568 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2016-08-12 23:08
New changeset 71a7db7ceabc by Alexander Belopolsky in branch 'default':
Issue #24773: Skip system tests for transitions in year 2037 and later.
https://hg.python.org/cpython/rev/71a7db7ceabc
msg273003 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2016-08-17 23:56
New changeset 617104a6b759 by Alexander Belopolsky in branch 'default':
Issue #24773: Include Tallinn 1999-10-31 transition in tests.
https://hg.python.org/cpython/rev/617104a6b759
msg273515 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2016-08-23 20:39
As far as I can tell, the buildbots are happy now.  Closing.  Please open new issues if missed anything.
msg284627 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2017-01-04 11:02
New changeset 5c02f689c62c by Victor Stinner in branch '3.6':
Issue #24773: fix datetime.time constructor docstring
https://hg.python.org/cpython/rev/5c02f689c62c
msg284632 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2017-01-04 11:55
Two bugs were found in the implementation: issue #29100 and issue #29140.
History
Date User Action Args
2022-04-11 14:58:19adminsetgithub: 68961
2017-01-04 11:55:55vstinnersetmessages: + msg284632
2017-01-04 11:02:38python-devsetmessages: + msg284627
2016-08-23 20:39:56belopolskysetstatus: open -> closed
resolution: fixed
messages: + msg273515
2016-08-17 23:56:22python-devsetmessages: + msg273003
2016-08-12 23:08:19python-devsetmessages: + msg272568
2016-08-12 02:01:06martin.pantersetmessages: + msg272489
2016-08-11 15:01:54python-devsetmessages: + msg272452
2016-08-11 14:39:36belopolskysetmessages: + msg272449
2016-08-11 14:34:16belopolskysetmessages: + msg272448
2016-08-11 04:05:58martin.pantersetmessages: + msg272398
2016-07-31 10:53:20koobssetmessages: + msg271734
2016-07-30 15:41:08python-devsetmessages: + msg271696
2016-07-30 15:37:44belopolskysetmessages: + msg271695
2016-07-28 15:29:01belopolskysetmessages: + msg271559
2016-07-27 21:26:26belopolskysetmessages: + msg271473
2016-07-26 21:21:41belopolskysetmessages: + msg271414
2016-07-26 21:15:02belopolskysetmessages: + msg271413
2016-07-26 17:13:45belopolskysetmessages: + msg271396
2016-07-26 16:23:25python-devsetmessages: + msg271393
2016-07-26 02:29:18martin.pantersetmessages: + msg271318
2016-07-26 01:14:55belopolskysetmessages: + msg271315
2016-07-26 01:01:28belopolskysetmessages: + msg271313
2016-07-25 17:54:56python-devsetmessages: + msg271300
2016-07-25 06:47:50koobssetmessages: + msg271239
2016-07-25 05:12:42belopolskysetmessages: + msg271234
2016-07-25 05:09:37martin.pantersetmessages: + msg271233
2016-07-25 04:58:20martin.pantersetmessages: + msg271229
2016-07-25 00:37:00python-devsetmessages: + msg271192
2016-07-24 18:41:19python-devsetmessages: + msg271178
2016-07-24 16:18:12belopolskysetmessages: + msg271167
2016-07-24 16:07:00belopolskysetmessages: + msg271166
2016-07-24 12:29:22martin.pantersetmessages: + msg271147
2016-07-24 04:18:46koobssetmessages: + msg271128
2016-07-24 04:13:48koobssetfiles: + koobs-freebsd-current-usr-share-zoneinfo.txt

messages: + msg271127
2016-07-23 15:36:42belopolskysetmessages: + msg271087
2016-07-23 15:17:01python-devsetmessages: + msg271086
2016-07-23 14:57:10belopolskysetmessages: + msg271081
2016-07-23 11:24:26koobssetresolution: fixed -> (no value)

messages: + msg271073
nosy: + koobs
2016-07-23 06:48:05martin.pantersetmessages: + msg271063
2016-07-23 03:09:59martin.pantersetstatus: closed -> open
nosy: + martin.panter
messages: + msg271048

2016-07-22 22:54:10belopolskysetstatus: open -> closed
superseder: Document PEP 495 (Local Time Disambiguation) features
resolution: fixed
stage: commit review -> resolved
2016-07-22 22:53:22belopolskylinkissue27595 dependencies
2016-07-22 22:47:13python-devsetnosy: + python-dev
messages: + msg271040
2016-07-22 22:45:14belopolskysetfiles: + issue24773-final.diff

messages: + msg271039
2016-07-18 23:54:37belopolskysetfiles: + issue24773-s3-4.diff

messages: + msg270797
2016-07-18 16:53:16belopolskysetfiles: + issue24773-s3-3.diff

messages: + msg270776
2016-07-16 17:20:26belopolskysetnosy: + vstinner

stage: needs patch -> commit review
2016-07-16 17:17:28belopolskysetfiles: + issue24773-s3-2.diff

messages: + msg270574
2016-03-21 23:01:18belopolskysethgrepos: + hgrepo335
2015-10-03 03:28:46stubsetnosy: + stub
2015-09-29 09:33:08akirasetnosy: + akira
2015-09-29 04:24:42tim.peterssetnosy: + tim.peters
2015-09-29 03:54:42belopolskysetfiles: + issue24773-s3.diff
2015-09-29 01:53:33belopolskysettitle: Add local time disambiguation flag to datetime -> Implement PEP 495 (Local Time Disambiguation)
messages: + msg251811
stage: needs patch
2015-09-17 07:04:10ethan.furmansetnosy: - ethan.furman
2015-08-01 21:49:11belopolskysetfiles: + ltdf-2.patch
2015-08-01 21:42:00belopolskysetmessages: + msg247831
2015-08-01 19:35:32ethan.furmansetnosy: + ethan.furman
2015-08-01 19:17:27belopolskycreate