error in datetime.timestamp on windows

Hi,

i found few similar bugs but all of them seems to be closed in older versions of python.
On windows (10, 64b) I get an OSError if I try to get timestamp from datetime.datetime object for some dates:

>>> datetime.datetime(year=2021, month=11, day=13).timestamp()

1636758000.0

>>> datetime.datetime(year=3021, month=11, day=13).timestamp()

Traceback (most recent call last):

  File "<stdin>", line 1, in <module>

OSError: [Errno 22] Invalid argument

>>> datetime.datetime(year=1021, month=11, day=13).timestamp()

Traceback (most recent call last):

  File "<stdin>", line 1, in <module>

OSError: [Errno 22] Invalid argument

>>> sys.version

'3.9.2 (tags/v3.9.2:1a79785, Feb 19 2021, 13:44:55) [MSC v.1928 64 bit (AMD64)]'

>>>

Hi :)
So these are two different cases. In the case of the year 1021, what is the output you are expecting? Since timestamp returns the time since epoc, I think it "makes sense" for it to fail, since it's before 1970.

Regarding the second case, I looked into it a bit and it seems the limit is in the C functions used for the conversion. Specifically localtime_s and the time_t (=__time64_t). localtime_s fails and returns an error since the value timestamp is too big. I found a very similar issue in this github ticket.

I'm not familiar how such issues are usually solved. Maybe in these cases a slower python routine can be used instead of a C routine? I'd like to give it a go if a Dev can give me a small direction to the expected solution and therelevancy of it :)

Hi,

For the 1021 the negative value would make sense I guess.
This is the result on my Ubuntu (64b) machine:

>>> import datetime
>>> datetime.datetime(year=2021, month=11, day=13).timestamp()
1636758000.0

>>> datetime.datetime(year=1021, month=11, day=13).timestamp()
-29920237064.0

>>> datetime.datetime(year=3021, month=11, day=13).timestamp()
33193666800.0

>>> import sys
>>> sys.version
'3.8.10 (default, Mar 15 2022, 12:22:08) \n[GCC 9.4.0]'

However this is older version (default for the Ubuntu 20.04 LTS) that I must use on the windows machine.

From the datetime.timestamp() documentation:

Naive datetime instances are assumed to represent local time and this method relies on the platform C mktime() function to perform the conversion. Since datetime supports wider range of values than mktime() on many platforms, this method may raise OverflowError for times far in the past or far in the future.

(Doesn't say OSError, though...)

@kecmen

@kecmen after looking deeper into the docs I found that "aware" datetime instances don't have this issue -

For aware datetime instances, the return value is computed as:

(dt - datetime(1970, 1, 1, tzinfo=timezone.utc)).total_seconds()

This means that adding a timezone will allow you to use the timestamp function without the issue you raised.

from my windows machine-

>>> import datetime
>>> datetime.datetime(year=2021, month=11, day=13, tzinfo=datetime.timezone.utc).timestamp()
1636761600.0
>>> datetime.datetime(year=1021, month=11, day=13, tzinfo=datetime.timezone.utc).timestamp()
-29920233600.0
>>> datetime.datetime(year=3021, month=11, day=13, tzinfo=datetime.timezone.utc).timestamp()
33193670400.0

Does this solve your issue?

@yourlefthandman

HI @yourlefthandman ,

thanks, for me it solved the issue. Question is, whether this shouldn't behave the same way like or linux by default.

Oh Nice. Got nealy the same issue and can fix it now!

Duplicates: #81708, #94414

thanks, for me it solved the issue. Question is, whether this shouldn't behave the same way like or linux by default.

I think it's platform-specific so I don't think this should be done (unless we do have a bug in the Windows implementation). I'm closing this as a duplicate of #81708, but we have a workaround. For the root issue, it appears that it has been located: #81708 (comment).

Navigation Menu

Repository navigation

error in datetime.timestamp on windows #94757

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

error in datetime.timestamp on windows #94757

Description

Activity

yourlefthandman commented on Jul 11, 2022

kecmen commented on Jul 11, 2022

pochmann commented on Jul 11, 2022

yourlefthandman commented on Jul 13, 2022

kecmen commented on Jul 14, 2022

MaggesMitX commented on Aug 30, 2022

StanFromIreland commented on Mar 9, 2025

picnixz commented on Mar 30, 2025

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions