Message78523
- 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 struct_time in UTC".
- You are no doubt correct that under Unix, "Unix time" is actually
used, however the phrase "a time expressed in seconds since the epoch"
implies the number of *elapsed* seconds since the epoch, which is not
the same thing as Unix time. 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.
The documentation should make it clear either that
(1) the numeric representation of times is based on Unix time and
assumes a 86400 SI second day, and therefore (1a) the number of elapsed
SI seconds between two numeric times is not necessarily equal to the
difference of those two numbers and (1b) gmtime accurately converts a
UTC time, or that
(2) the numeric representation of times is based on a 86400 non-SI
second day, and therefore (2a) the number of elapsed (non-SI) seconds
between two numeric times is equal to the difference of the two numbers
and (2b) gmtime accurately converts a non-UTC Universal Time, or that
(3) the numeric representation of times is based on TAI and assumes a
86400 SI second day, and therefore (1a) the number of elapsed SI seconds
between two numeric times is equal to the difference of those two
numbers and (1b) gmtime accurately converts a TAI time, or that
(4) the numeric representation of time is based on SI-seconds past the
epoch and allows variable length days, and therefore (4a) the number of
elapsed SI seconds between two numeric times is equal to the difference
of the two numbers and (4b) gmtime only accurately converts a UTC time
that is before the next future leap-second adjustment (whenever that may
be), or that
(5) the numeric representation of time is platform-dependent and any one
of the above may hold.
Note that the only significant difference in implementation between (1),
(2), and (3) is what time.time() actually returns: Unix time, a non-UTC
Universal Time, or TAI.
Since the time.localtime is most-likely implemented as an integral-
minute offset from time.gmtime, the same issues arise for time.localtime
and time.mktime.
The same documentation issue crops up in
<http://docs.python.org/library/datetime.html> and indirectly
(calendar.timegm) in <http://docs.python.org/library/calendar.html> |
|
Date |
User |
Action |
Args |
2008-12-30 12:21:59 | luckmor | set | recipients:
+ luckmor, loewis, georg.brandl |
2008-12-30 12:21:59 | luckmor | set | messageid: <1230639719.65.0.526237015883.issue4775@psf.upfronthosting.co.za> |
2008-12-30 12:21:59 | luckmor | link | issue4775 messages |
2008-12-30 12:21:57 | luckmor | create | |
|