[issue33579] calendar.timegm not always an inverse of time.gmtime

2018-05-20 Thread Alexander Belopolsky
Alexander Belopolsky added the comment: Well, even in non-POSIX mode timegm and gmtime are the inverse of one another in BSD. The problem that you see stems from the fact that time.gmtime is implemented as a call to the namesake C function while

[issue33579] calendar.timegm not always an inverse of time.gmtime

2018-05-20 Thread Eitan Adler
Eitan Adler added the comment: FTR this was entirely self-inflicted: I had a setting which explicitly asked for non-posix gmtime. That said, leaving this open for the same reasons as above. -- ___ Python tracker

[issue33579] calendar.timegm not always an inverse of time.gmtime

2018-05-20 Thread Eitan Adler
Eitan Adler added the comment: Relevant conversation: https://lists.freebsd.org/pipermail/freebsd-standards/2018-May/003714.html -- ___ Python tracker

[issue33579] calendar.timegm not always an inverse of time.gmtime

2018-05-20 Thread Alexander Belopolsky
Alexander Belopolsky added the comment: I was able to reproduce this issue on Linux as follows >>> import time, calendar, os >>> os.environ['TZ'] = 'right/UTC' # "right" timezones account for leap seconds >>> time.tzset() >>>

[issue33579] calendar.timegm not always an inverse of time.gmtime

2018-05-20 Thread Eitan Adler
Eitan Adler added the comment: Thanks! I've confirmed this is the case on my system and will be starting a conversation about fixing it. In the meantime I am leaving this bug open since we may want to detect this case in python and correct for it. --

[issue33579] calendar.timegm not always an inverse of time.gmtime

2018-05-19 Thread Martin Panter
Martin Panter added the comment: According to Wikipedia, there were 24 leap seconds before Feb 2009. So my guess is Eitan’s “gmtime” implementation is calculating the date as if the timestamp (1234567899) includes leap seconds, as in

[issue33579] calendar.timegm not always an inverse of time.gmtime

2018-05-19 Thread Tim Peters
Tim Peters added the comment: They both look wrong to me. Under 3.6.5 on Win10, `one` and `three` are the same. Python 3.6.5 (v3.6.5:f59c0932b4, Mar 28 2018, 17:00:18) [MSC v.1900 64 bit (AMD64)] on win32 time.struct_time(tm_year=2009, tm_mon=2, tm_mday=13, tm_hour=23,

[issue33579] calendar.timegm not always an inverse of time.gmtime

2018-05-19 Thread Serhiy Storchaka
Change by Serhiy Storchaka : -- nosy: +belopolsky ___ Python tracker ___ ___

[issue33579] calendar.timegm not always an inverse of time.gmtime

2018-05-19 Thread Eitan Adler
Change by Eitan Adler : -- components: +Library (Lib) type: -> behavior ___ Python tracker ___

[issue33579] calendar.timegm not always an inverse of time.gmtime

2018-05-19 Thread Eitan Adler
New submission from Eitan Adler : How to reproduce: ∴cat bad.py import time import calendar one = time.gmtime(1234567899) two = calendar.timegm(time.gmtime(1234567899)) three = time.gmtime(two) print(one) print(two) print(three) print(one == three) Expected behavior: