STINNER Victor added the comment:

time.time() is not quite UTC on Unix

Handling time is a complex task, so we should enhance the doc to help users. If there are multiple cases, we can list them: "time.time() uses UTC timezone with or without leap seconds". Maybe with a link to https://en.wikipedia.org/wiki/Unix_time ? ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue29026> _______________________________________

Eric Appelt added the comment: I looked at the documentation and implementation and made a patch to hopefully clarify the issue. I also have some comments: - The term "epoch" is actually defined at the top of the page with instructions for how to determine it, i.e. run "gmtime(0)". - I added a definition for the term "seconds since the epoch" since this typically means the number of seconds that have elapsed since the epoch excluding leap seconds, although it may vary by platform. - I'm a bit uncomfortable with potential confusion regarding Windows, since the Windows epoch begins on 1601, although we adjust it to 1970: https://github.com/python/cpython/blob/d739274e7b69f63263054cc24684e7e637264... I didn't add a note in the patch as I am not a windows developer, but I wonder if there could be some confusion. - Even though its redundant with the top of the page, I added specific clarification to time.time() as it appears that most readers are going to navigate to that anchor specifically and not read the discussion of what we mean by "epoch" above. - I need to test my assertion that Windows does not count leap seconds. I'm pretty sure but not 100% confident that I am correct from what I read, but I need to find someone with a windows machine tomorrow and actually check it. The windows documentation for the FILETIME structure suggests that leap seconds might be counted - https://msdn.microsoft.com/en-us/library/windows/desktop/ms724284(v=vs.85).a... - but I think this is just an oversight in the documentation. - Just out of personal curiousity does anyone have an example of a legacy UNIX system that counts leap seconds in the epoch? This seems tricky to do as I would presume that the OS would need some table that would be updated whenever the astronomers declare a new leap second. ---------- keywords: +patch Added file: http://bugs.python.org/file46005/29026_unixtime_v1.patch _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue29026> _______________________________________

Eric Appelt added the comment: I had some checks performed on a Windows platform using the following snippet: # valid for 2016 import time def check(): t = time.gmtime() print(46*86400*365 + 11*86400 + (t.tm_yday-1)*86400 + t.tm_hour*3600 + t.tm_min*60 + t.tm_sec) print(time.time()) print(time.gmtime(0)) check() This ensures that the time since the epoch is counted excluding leap seconds if the first two lines of output are approximately the same (to nearest second), and finally that the epoch is the Unix epoch. On Python 3.6.0 (v3.6.0:41df79263a11, Dec 23 2016, 07:18:10) [MSC v.1900 32 bit (Intel)] on win32 I see: 1482502941 1482502941.9609053 time.struct_time(tm_year=1970, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=3, tm_yday=1, tm_isdst=0) Unless there is major variation among windows versions on how FILETIMEs are calculated and the results of basic system calls, I feel fairly confident now that the calculation of time since the epoch in CPython is the same on Windows as it is in POSIX-compliant platforms. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue29026> _______________________________________

STINNER Victor added the comment: New changeset 23557d59b819f57800ddef0b1373acef8e024670 by Victor Stinner in branch 'master': bpo-29026: Clarify documentation of time.time (#34) https://github.com/python/cpython/commit/23557d59b819f57800ddef0b1373acef8e0... ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue29026> _______________________________________

Nick Coghlan added the comment: New changeset 23557d59b819f57800ddef0b1373acef8e024670 by Victor Stinner in branch 'ncoghlan-devguide-link': bpo-29026: Clarify documentation of time.time (#34) https://github.com/python/cpython/commit/23557d59b819f57800ddef0b1373acef8e0... ---------- nosy: +ncoghlan _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue29026> _______________________________________

Changes by Mariatta Wijaya <mariatta.wijaya@gmail.com>: ---------- pull_requests: +348 _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue29026> _______________________________________

Mariatta Wijaya added the comment: Hi, does this need backport to 2.7? I'm getting a lot of conflicts while trying to do that... Not sure how to proceed. ---------- nosy: +Mariatta _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue29026> _______________________________________

Mariatta Wijaya added the comment: New changeset 8c851fa3d3044d5bc53e9f931129f5987ece401d by Mariatta in branch '3.5': bpo-29026: Clarify documentation of time.time (GH-34) (GH-418) https://github.com/python/cpython/commit/8c851fa3d3044d5bc53e9f931129f5987ec... ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue29026> _______________________________________