Akira Li added the comment: POSIX timestamp doesn't count (literally) past/future leap seconds. It allows to find out that the timestamp 2**31-1 corresponds to 2038-01-19T03:14:07Z (UTC) regardless of how many leap seconds will occur before 2038:
>>> from datetime import datetime, timedelta >>> str(datetime(1970,1,1) + timedelta(seconds=2**31-1)) '2038-01-19 03:14:07' If you use "right" timezone then mktime() may count leap seconds: $ TZ=right/UTC ./python >>> import time >>> time.mktime((2012, 6, 30, 23, 59, 59, -1, -1, -1)) 1341100823.0 >>> time.mktime((2012, 6, 30, 23, 59, 60, -1, -1, -1)) 1341100824.0 >>> time.mktime((2012, 7, 1, 0, 0, 0, -1, -1, -1)) 1341100825.0 It is a different time scale. There are no leap seconds in TAI: >>> str(datetime(1970,1,1, 0,0, 10) + timedelta(seconds=1341100825)) '2012-07-01 00:00:35' i.e., 2012-07-01 00:00:35 TAI that corresponds to 2012-07-01 00:00:00 UTC. Each positive leap second increases the difference TAI-UTC (on 2015-07-01UTC it will be 36 [1]). TAI-UTC in the future (more than 6 months) is unknown but it is less than ~200 seconds until 2100 [2]. It might be convenient to think about datetime as a broken-down timestamp and therefore (datetime(2012,6,30,23,59,60) - epoch) == (datetime(2012,7, 1, 0, 0, 0) - epoch) The code [3] that silently truncates 60 to 59 when datetime constructor is called implicitly should retire. Use case: parse timestamps that might include a leap second [4] [1] https://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat [2] http://www.ucolick.org/~sla/leapsecs/year2100.html [3] https://bugs.python.org/msg155689 [4] http://stackoverflow.com/q/21027639 ---------- nosy: +akira _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23574> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
