$ ./python -m test -vuall test_datetime
...
======================================================================
FAIL: test_timestamp_naive (test.datetimetester.TestDateTime_Pure)
----------------------------------------------------------------------
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
or even reimplementations of buggy time functions in the time and
datetime modules. Whether or not this is something that is worth
fixing is a question for the affected NetBSD users.

I would say, for the purposes of this issue - add a skip for NetBSD to
the failing test and add a test for another date that can be included
on all systems.

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 Issue 29097, probing a date before 1970?

> The documentation only says “datetime.timestamp” calls “mktime”

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
mktime.  In fact, mktime should not be called anywhere in the datetime
module. See <https://github.com/python/cpython/blob/a2314283ff87c65e1745a42c2f2b716b1a209128/Modules/_datetimemodule.c#L5315>.

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:
>
> Martin Panter <vadmium+py@gmail.com> added the comment:
>
> 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 Issue 29097, probing a date before 1970?
>
> ----------
> nosy: +martin.panter
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue31894>
> _______________________________________