[issue4775] Incorrect documentation - UTC time

Changes by Alexander Belopolsky : -- status: pending -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: h

[issue4775] Incorrect documentation - UTC time

Alexander Belopolsky added the comment: Based on the discussion so far, I am going to close this as "invalid". -- assignee: georg.brandl -> belopolsky resolution: -> invalid status: open -> pending ___ Python tracker

[issue4775] Incorrect documentation - UTC time

Alexander Belopolsky added the comment: """ The gmtime() function shall convert the time in seconds since the Epoch pointed to by timer into a broken-down time, expressed as Coordinated Universal Time (UTC). """ In a technical sense, this is correct. The result of gmtime() is UTC time, but

[issue4775] Incorrect documentation - UTC time

Alexander Belopolsky added the comment: Python implementation of time functions certainly has nothing to do with UT1, which is the time as measured by (modern) sun dials. The correct name would be POSIX time. As explained in POSIX rationale, """ Coordinated Universal Time (UTC) includes lea

[issue4775] Incorrect documentation - UTC time

Changes by Terry J. Reedy : -- versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2 -Python 2.5 ___ Python tracker ___ ___ Python-

[issue4775] Incorrect documentation - UTC time

Marc-Andre Lemburg added the comment: FWIW: POSIX defines Unix time_t *not* to include leap seconds. You can easily check whether your platform or C lib behaves POSIX-ly correct or not: POSIX: 1986-12-31 23:59:59 UTC == 536457599 ticks With leap seconds: == 536457612 ticks

[issue4775] Incorrect documentation - UTC time

David Morley added the comment: > I propose to add this sentence to the explanation of the epoch: > > "It is platform-dependent whether or not 'seconds since the epoch' > includes leap seconds. Most systems likely implement `Unix time`_" That solution is fine. Anyone sufficiently concerned abo

[issue4775] Incorrect documentation - UTC time

Martin v. Löwis added the comment: > It was the fact that (at least under Mac OS X) the numeric > representation assumes a 86400 second day that led me to > believe that non-SI seconds and hence a non-UTC version of Universal > Time, such as UT1 was being used. AFAICT, Mac OSX also uses Unix ti

[issue4775] Incorrect documentation - UTC time

David Morley added the comment: - My use of mktime was a bad choice for an example, since "local time" is not defined and does not necessarily bear any relationship to UTC. However the documentation does claim that time.gmtime converts "a time expressed in seconds since the epoch" to "a struc

[issue4775] Incorrect documentation - UTC time

Martin v. Löwis added the comment: > The difference is that UTC includes leap seconds, whereas UT1 does not (see > ). The > conversion routines ignore leap seconds, e.g., > (time.mktime((2000,1,1,12,0,0,0,0,0))- > time.mktime((1990,1,1,

[issue4775] Incorrect documentation - UTC time

New submission from David Morley : There is a systemic error in the Python documentation on time (such as ). The term UTC is used incorrectly in the documentation where the term UT1 should be used. The difference is that UTC includes leap seconds, wher