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

Irit Katriel added the comment: The docs now say "The epoch is the point where the time starts, and is platform dependent. For Unix, the epoch is January 1, 1970, 00:00:00 (UTC). To find out what the epoch is on a given platform, look at time.gmtime(0)." which I believe covers this issue.

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

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 byte

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

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

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

Alexander Belopolsky added the comment: > It is possible to inspect all stdlib functions that use time module and > determine for some of them whether they will break if gmtime(0) is not > 1970 or "right" zoneinfo is used or any non-POSIX time encoding is > used. But it is hard to maintain such a

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

Akira Li added the comment: > Alexander Belopolsky added the comment: > > In the context of Python library documentation, the word "encoding" > strongly suggests that you are dealing with string/bytes. The > situation may be different in C. If you want to refer to something > that is defined by

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

Alexander Belopolsky added the comment: In the context of Python library documentation, the word "encoding" strongly suggests that you are dealing with string/bytes. The situation may be different in C. If you want to refer to something that is defined by the POSIX standard you should use the

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

Akira Li added the comment: > Alexander Belopolsky added the comment: > > 1. It is not the job of the time module documentation to warn about > "many functions in the stdlib." What are these functions, BTW? The e-mail linked in the first message of this issue msg226539 enumerates some of the fu

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

Alexander Belopolsky added the comment: I don't like the proposed note. 1. It is not the job of the time module documentation to warn about "many functions in the stdlib." What are these functions, BTW? 2. What is "calendar time in POSIX encoding"? This sounds like what time.asctime() return

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

Changes by Ned Deily : -- nosy: +belopolsky ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python

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

Chris Rebert added the comment: Ping. This small patch has been waiting nearly 3 months for a review. -- ___ Python tracker ___ ___ Py

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

Changes by Chris Rebert : -- nosy: +cvrebert ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

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

New submission from Akira Li: See discussion on Python-ideas https://mail.python.org/pipermail/python-ideas/2014-September/029228.html -- assignee: docs@python components: Documentation files: docs-time-epoch_is_1970.diff keywords: patch messages: 226539 nosy: akira, docs@python priority