New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[doc] documentation incorrectly says that “datetime.timestamp” calls “mktime” #76075
Comments
$ ./python -m test -vuall test_datetime
... ====================================================================== Traceback (most recent call last):
File "/home/serhiy/py/cpython3.7/Lib/test/support/__init__.py", line 1622, in inner
return func(*args, **kwds)
File "/home/serhiy/py/cpython3.7/Lib/test/datetimetester.py", line 1977, in test_timestamp_naive
self.assertEqual(t.timestamp(), 18000.0)
AssertionError: 14400.0 != 18000.0 ... Simple reproducer: $ TZ=EST+05EDT,M3.2.0,M11.1.0 ./python -c 'import datetime; print(datetime.datetime(1970, 1, 1).timestamp())'
14400.0 It should print 18000.0 (5 hours) instead of 14400.0 (4 hours). |
I don't have access to NetBSD and this looks like a bug in the system implementation of localtime. The timestamp method is implemented by probing system localtime in the vicinity of UTC timestamp. What does time.localtime(14400) with these TZ settings? |
$ TZ=EST+05EDT,M3.2.0,M11.1.0 ./python -c 'import time; print(time.localtime(14400))'
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=1) |
I hate this long form display! Next time please use time.localtime(14400)[:]. Do you agree that this is a system bug? On my Mac, I get $ python -c 'import time; print(time.localtime(14400)[:])'
(1969, 12, 31, 23, 0, 0, 2, 365, 0) |
I posted a wrong command, but fortunately I am in New York, so it did not matter $ TZ=EST+05EDT,M3.2.0,M11.1.0 python -c 'import time;print(time.localtime(14400)[:])'
(1969, 12, 31, 23, 0, 0, 2, 365, 0) |
I'm not a datetime expert. What is the better way to skip the test? Is it worth to change the date to say (1970, 3, 9) for which the correct result is obtained on this system? |
I am not sure. This is a system bug and we often provide work-arounds I would say, for the purposes of this issue - add a skip for NetBSD to If motivated, please open a separate issue for the time.localtime() bug. |
Are you sure it is a “system” bug? As far as I understand, at least Posix does not require support for local time before 1970. See <http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16\>. But why is localtime(14400) relevant? The documentation only says “datetime.timestamp” calls “mktime”, which should be valid since the UTC-5 timezone offset will give a positive timestamp. Perhaps is this similar to bpo-29097, probing a date before 1970? |
Indeed. See <https://docs.python.org/3/library/datetime.html#datetime.datetime.timestamp\>. This is a documentation bug. Since 3.6 the timestamp does not call For the explanation of why mktime is not a good API, see PEP-495. On Sun, Oct 29, 2017 at 9:30 PM, Martin Panter <report@bugs.python.org> wrote:
|
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: