Python datetime.timestamp() issue

问题

I find the datetime.timestamp() function return different value on Linux and Windows. Here is a simple to to replicate it:

from datetime import date, time, datetime, timedelta

def main(): 
    dt = datetime(2000, 1, 1)
    edt = datetime(2006, 12, 31)

    fname = 't1.csv'
    f = open(fname, 'w')
    f.write('date,timestamp\n')
    while dt <= edt:
        f.write('{0:%Y-%m-%d},{1:.0f}\n'.format(dt, dt.timestamp()))
        dt += timedelta(days=1)
    f.close()

return 0

Here is the LAST different part from Windows: (Windows7 64 + Python3.4.3 64)

...
2006-10-30,1162180800
2006-10-31,1162267200
2006-11-01,1162353600
2006-11-02,1162440000
2006-11-03,1162526400
2006-11-04,1162612800
2006-11-05,1162699200
...

Here is the corresponding Linux output: (RedHat6 64 + Python 3.4.3 64)

...
2006-10-30,1162184400
2006-10-31,1162270800
2006-11-01,1162357200
2006-11-02,1162443600
2006-11-03,1162530000
2006-11-04,1162616400
2006-11-05,1162702800
...

Systems all using the EST with automatic DST adjustment. Some observations:

• the linux output seems to be correct
• no difference observed after 2006 (I did not test above 12/31/2015)
• the difference seems to be 1 hour/3600 seconds
• the difference seems to happen only in those days around the DST change in that year (or around the time EU/US has different DST change date.)

Just wondering why timestamp() function behaves differently on windows and linux.

回答1:

datetime.timestamp() on a naive datetime object calls mktime() internally i.e., the input is interpreted as the local time. Local time definitions may differ between systems.

C mktime() may return a wrong result if the local timezone had different utc offset in the past and a historical timezone database is not used. python has no access to the tz database on Windows.

You may get different results if applications use different tzdata versions. You may also get different results for ambiguous times (e.g., during DST transitions) if different mktime() implementations are used (all else being equal).

To get the same result on different systems, use pytz module (the same version on different systems that uses bundled with the Python package zoneinfo):

#!/usr/bin/env python3
from datetime import datetime
import pytz  # $ pip install pytz

tz = pytz.timezone('America/New_York')
for tt in [(2006, 10, 30),
           (2006, 10, 31),
           (2006, 11, 1),
           (2006, 11, 2),
           (2006, 11, 3),
           (2006, 11, 4),
           (2006, 11, 5)]:
    dt = datetime(*tt)
    ts = tz.localize(dt, is_dst=None).timestamp()
    print("{dt:%Y-%m-%d},{ts:.0f}".format(**vars()))

Output (pytz.__version__ == 2014.10)

2006-10-30,1162184400
2006-10-31,1162270800
2006-11-01,1162357200
2006-11-02,1162443600
2006-11-03,1162530000
2006-11-04,1162616400
2006-11-05,1162702800

回答2:

From doing some research on your issue I found this link it talks about how the start dates for systems are different I would think that linux is like unix and uses 01/01/1970 as its start time and windows uses a time much earlier and dependent on what you are doing as from what I gather windows is either 01/01/1601 if you are saving files to the file system but the time used to calculate a timestamp is 31/12/1601. So it looks like a difference in what they see as the start of time if you take a further look you will see that the actual start times are different in terms of 12:00:00AM for example.

来源：https://stackoverflow.com/questions/34622302/python-datetime-timestamp-issue