date:20141202

[issue22356] mention explicitly that stdlib assumes gmtime(0) epoch is 1970

2014-12-02 Thread Akira Li

Akira Li added the comment:

Alexander Belopolsky added the comment:

I've provide the direct quote from *C* standard ...

I understand that C standard uses the word encoding, but it does so
for a reason that is completely unrelated to the choice of epoch.
Encoding is how the bytes in memory should be interpreted as number
of seconds or some other notion of time. For, example two's
complement little-endian 32-bit signed int is an example of valid
time_t encoding, another example would be IEEE 754 big-endian 64-bit
double. Note that these choices are valid for both C and POSIX
standards.

I agree one *part* of encoding is how time_t is *represented* in
memory but it is not the only part e.g.:

The mktime function converts the broken-down time, expressed as local
time, in the structure pointed to by timeptr into a calendar time
value with the same encoding as that of the values returned by the
time function.

notice: the same encoding as ... returned by the time function.

time() function can return values with different epoch (implementation
defined). mktime() is specified to use the *same* encoding i.e., the
same epoch, etc.

i.e., [in simple words] we have calendar time (Gregorian date, time) and
we can convert it to a number (e.g., Python integer), we can call that
number seconds and we can represent that number as some (unspecified)
bit-pattern in C.

I consider the whole process of converting time to a bit-pattern in
memory as encoding i.e., 32/64, un/signed int/754 double is just
*part* of it e.g.,

1. specify that 1970-01-01T00:00:00Z is zero (0)
2. specify 0 has time_t type
3. specify how time_t type is represented in memory.

I may be wrong that C standard includes the first item in time
encoding.

If you google for your phrase time in POSIX encoding, this issue is
the only hit. This strongly suggests that your choice of words is not
the most natural.

I've googled the phrase (no surrounding quotes) and the links talk about
time encoded as POSIX time [1] and some *literally* contain the phrase
*POSIX encoding* [2] because *Python* documentation for calendar.timegm
contains it [3]:

[timegm] returns the corresponding Unix timestamp value, assuming an
epoch of 1970, and the POSIX encoding. In fact, time.gmtime() and
timegm() are each others’ inverse.

In an effort to avoid personal influence, I've repeated the expreriment
using Tor browser and other search engines -- the result is the same.

timegm() documentation might be the reason why I've used the phrase.

I agree POSIX encoding might be unclear. The patch could be replaced
by any phrase that expresses that some functions in stdlib assume that
time.time() returns (+/- fractional part) seconds since the Epoch as
defined by POSIX [4].

[1] http://en.wikipedia.org/wiki/Unix_time#Encoding_time_as_a_number
[2]
http://ruslanspivak.com/2011/07/20/how-to-convert-python-utc-datetime-object-to-unix-timestamp/
[3] https://docs.python.org/3/library/calendar.html#calendar.timegm
[4]
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_15

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22356
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

1 2 >

1 - 100 of 117 matches

Mail list logo