Inconsistencies with datetime.fromtimestamp(t) when t < 0

@zooba

BPO	36439
Nosy	@zooba, @pganssle, @BoboTiG, @Dobatymo

^{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:

assignee = None
closed_at = None
created_at = <Date 2019-03-26.15:18:26.163>
labels = ['3.8', 'type-bug', '3.7']
title = 'Inconsistencies with datetime.fromtimestamp(t) when t < 0'
updated_at = <Date 2020-10-14.01:11:02.349>
user = 'https://github.com/BoboTiG'

bugs.python.org fields:

activity = <Date 2020-10-14.01:11:02.349>
actor = 'Dobatymo'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = []
creation = <Date 2019-03-26.15:18:26.163>
creator = 'Tiger-222'
dependencies = []
files = []
hgrepos = []
issue_num = 36439
keywords = []
message_count = 8.0
messages = ['338893', '338894', '338896', '339038', '355822', '355831', '371200', '378591']
nosy_count = 5.0
nosy_names = ['steve.dower', 'p-ganssle', 'Tiger-222', 'Dobatymo', 'Paul Anton Letnes']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue36439'
versions = ['Python 3.6', 'Python 3.7', 'Python 3.8']

Linked PRs

A similar issue was resolved with bpo-29097 (with 0 <= t <= 86399).

Here, we have an inconsistency between OSes when using datetime.fromtimestamp(t) when t < 0.
Tested on Python 3.6.7.

GNU/Linux:

>>> datetime.fromtimestamp(-1)
datetime.datetime(1970, 1, 1, 0, 59, 59)

macOS:

>>> datetime.fromtimestamp(-1)
datetime.datetime(1970, 1, 1, 0, 59, 59)

Windows (7 and 10):

>>> datetime.fromtimestamp(-1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 22] Invalid argument

I think having a similar behavior between all Oses would be great, right?

Reproduced on 3.6.8 and 3.7.3.

And also reproduced on 3.8.0a3.

From the documentation ( https://docs.python.org/3/library/datetime.html#datetime.datetime.fromtimestamp ):

fromtimestamp() may raise OverflowError, if the timestamp is out of the range
of values supported by the platform C localtime() or gmtime() functions, and
OSError on localtime() or gmtime() failure. It’s common for this to be
restricted to years in 1970 through 2038. Note that on non-POSIX systems that
include leap seconds in their notion of a timestamp, leap seconds are ignored
by fromtimestamp(), and then it’s possible to have two timestamps differing by
a second that yield identical datetime objects. See also utcfromtimestamp().

So this is indeed the documented behavior. I agree that it would be good to unify the behavior across platforms if possible, but I think this would require us to have our own implementation of localtime() and/or gmtime().

That said, it might be possible to implement fromtimestamp with some equivalent of datetime(1970, 1, 1) + timedelta(seconds=t) on Windows when the value falls outside the accepted range. We'd probably need some better tests under different time zones to make sure that that would be acceptable.

I think it may be a good idea to change the targeted version to 3.8 or 3.9, because this is a change to the documented behavior of the function (albeit a desirable one that can probably be considered backwards compatible).

This has been coming up in a few different contexts lately, so I think it would be really good if we could get some sort of fix for it.

One option is to implement our own versions of these APIs for use in Windows, but a thought occurred to me recently: we have not investigated the possibility of seeing if Microsoft would be willing to either add support for negative timestamps in their localtime() or gmtime() implementations or add a new API that *does* support negative timestamps. It would also be good to rule out the possibility that such APIs already exist but we just don't know about them (preliminary googling doesn't show anything, though possibly something can be done with the Win32 APIs? Not sure how or if those work in C and how big a lift it would be to maintain compatibility if can switch: https://docs.microsoft.com/en-us/windows/win32/sysinfo/time-functions?redirectedfrom=MSDN ).

Adding Steve Dower to the nosy list in case he can shed some light onto the possibility of native support.

I've emailed some colleagues to see what they can add here.

Ultimately, the Windows CRT is just doing arithmetic, since POSIX time formats do not resemble Windows time formats at all, so it's all emulation. So if we replaced it with our own calculation I don't think that would be the worst possible outcome.

I've encountered an issue on anaconda python on windows 10 v1909 which I suspect is related. It looks like no dates in 1970 can be converted to datetime.timestamp():

Python 3.8.2 (default, Apr 14 2020, 19:01:40) [MSC v.1916 64 bit (AMD64)]
Type 'copyright', 'credits' or 'license' for more information
IPython 7.13.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import datetime

In [2]: datetime.datetime(1970, 1, 2, 0, 0, 1, 123456).timestamp()
---------------------------------------------------------------------------

OSError                                   Traceback (most recent call last)
<ipython-input-2-0ac473af013b> in <module>
----> 1 datetime.datetime(1970, 1, 2, 0, 0, 1, 123456).timestamp()

OSError: [Errno 22] Invalid argument

In [3]: datetime.datetime(1971, 1, 2, 0, 0, 1, 123456).timestamp()
Out[3]: 31618801.123456

I've encountered an issue on anaconda python on windows 10 v1909 which I suspect is related. It looks like no dates in 1970 can be converted to datetime.timestamp():

Yeah... there is more related weirdness going on.

>>> datetime(1970, 1, 3).astimezone(timezone.utc)
datetime.datetime(1970, 1, 2, 16, 0, tzinfo=datetime.timezone.utc)
>>> datetime(1970, 1, 2).astimezone(timezone.utc)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 22] Invalid argument
>>> datetime(1970, 1, 1, 16, 0, tzinfo=timezone.utc)
datetime.datetime(1970, 1, 1, 16, 0, tzinfo=datetime.timezone.utc)

Fixed by #143463.

Negative timestamps are now accepted on Windows:

Python 3.15.0a5+ (heads/main:f5685a266b2, Jan 15 2026, 10:57:22) [MSC v.1944 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime
>>> from time import localtime
>>> localtime(-1)
time.struct_time(tm_year=1970, tm_mon=1, tm_mday=1, tm_hour=13, tm_min=59, tm_sec=59, tm_wday=3, tm_yday=1, tm_isdst=-1)

This broke test_time on some buildbots.

[edit] Looks like some of the new tests aren't compatible with time_t on 32-bit arches; they fail without the change too.

pythongh-80620: Fix test_time.test_gmtime() for 32-bit time_t

This broke test_time on some buildbots.

Right, I noticed that. I wrote #143861 to fix test_gmtime() on 32-bit systems.

gh-80620: Fix test_time.test_gmtime() for 32-bit time_t (#143861)

Thank you!

pythongh-80620: Fix test_time.test_gmtime() for 32-bit time_t (python…

pythongh-80620: Support negative timestamps on windows in `time.gmtim…

pythongh-80620: Fix test_time.test_gmtime() for 32-bit time_t (python…

This started failing now the US switched to DST:

Navigation Menu

Repository navigation

Inconsistencies with datetime.fromtimestamp(t) when t < 0 #80620

Linked PRs

9 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Inconsistencies with datetime.fromtimestamp(t) when t < 0 #80620

Description

Linked PRs

Activity

BoboTiG commented on Mar 26, 2019

BoboTiG commented on Mar 26, 2019

BoboTiG commented on Mar 26, 2019

pganssle commented on Mar 28, 2019

pganssle commented on Nov 1, 2019

zooba commented on Nov 1, 2019

PaulAntonLetnes commented on Jun 10, 2020

Dobatymo commented on Oct 14, 2020

9 remaining items

vstinner commented on Jan 15, 2026

vstinner commented on Jan 15, 2026

encukou commented on Jan 15, 2026

vstinner commented on Jan 15, 2026

encukou commented on Jan 15, 2026

hugovk commented on Mar 10, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions