Skip to content

datetime.timestamp() fails before 1970-01-02T01:00:00.000000 #94414

Closed as duplicate

Description

@dtyeos

Python 3.8.10
datetime 4.4
Windows 10

datetime(1970,1,1,0,0,0).timestamp()  # OSError: [Errno 22] Invalid argument
datetime(1970,1,1,23,59,59,999999).timestamp()  # OSError: [Errno 22] Invalid argument
datetime(1970,1,2,0,59,59,999999).timestamp()  # OSError: [Errno 22] Invalid argument

Minimal datetime where timestamp() is fine:

datetime(1970,1,2,1,0,0).timestamp()  # 86400.0

Activity

  1. added
    type-bugAn unexpected behavior, bug, or error
    on Jun 29, 2022
  2. dtyeos commented on Jun 29, 2022

    @dtyeos
    Author

    Probable duplicate of gh-817081

    Footnotes

    1. @erlend-aasland: edited the BPO link to a GitHub Issues link, for the convenience of the reader ↩

  3. dtyeos commented on Jun 29, 2022

    @dtyeos
    Author
    datetime(1970,1,1,0,0,0, tzinfo=None).timestamp()  # OSError: [Errno 22] Invalid argument
    datetime(1970,1,1,0,0,0, tzinfo=timezone.utc).timestamp()  # 0.0
    
  4. dignissimus commented on Jun 29, 2022

    @dignissimus
    Contributor

    Cannot reproduce this on Arch with python 3.10.5 with the system clock set to UTC+1. Perhaps this only affects Windows. Are you able to reproduce this using python 3.10?

    sam@samtop ~ % python                                                  
    Python 3.10.5 (main, Jun  6 2022, 18:49:26) [GCC 12.1.0] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> from datetime import datetime, timezone
    >>> datetime(1970,1,1,0,0,0, tzinfo=None).timestamp()
    -3600.0
    >>> datetime(1970,1,1,0,0,0, tzinfo=timezone.utc).timestamp()
    0.0
    >>> import time
    >>> time.tzname
    ('GMT', 'BST')
    >>> 
  5. dtyeos commented on Jun 30, 2022

    @dtyeos
    Author
    C:\>py -3.10
    Python 3.10.5 (tags/v3.10.5:f377153, Jun  6 2022, 16:14:13) [MSC v.1929 64 bit (AMD64)] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> from datetime import datetime, timezone
    >>> datetime(1970,1,1,0,0,0, tzinfo=None).timestamp()
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    OSError: [Errno 22] Invalid argument
    >>> datetime(1970,1,1,0,0,0, tzinfo=timezone.utc).timestamp()
    0.0
    >>> import time
    >>> time.tzname
    ('Romance Standard Time', 'Romance Daylight Time')
    >>>
    

    This should come from the fact that without any timezone specified, the lib relies on the Windows function which does not support times before the Epoch. The strange thing is that the whole day after the Epoch is unusable, which cannot be explained only by time zone.

  6. benpryke commented on Mar 21, 2023

    @benpryke

    While running property-based tests with Hypothesis, I discovered that datetime.timestamp() also fails with the same error on Windows 10 x64 for datetimes after datetime.datetime(3001, 1, 19, 7, 59, 59, 999999).

    Specifically:

    > datetime.datetime(3001, 1, 19, 7, 59, 59, 999999).timestamp()
    32536800000.0
    > datetime.datetime(3001, 1, 19, 8, 0, 0, 0).timestamp()
    OSError: [Errno 22] Invalid argument
    

    I suspect this is related to the max value of the argument to time.ctime on Windows 10 x64 as discussed in this Stack Overflow thread.

  7. achoum commented on Mar 21, 2024

    @achoum

    This issue is present on Windows 10 for Python 9, Python10 and Python11, and on Windows 11 for Python 11. I did not tested it on Python 9 and Python 10 on Windows 11.

    In addition to the timestamp() function, a similar error is raised with the astimezone() function. For example, the following code fail with an OSError: [Errno 22] Invalid argument error:

    import dateime
    a = datetime.datetime(1901, 12, 25)
    b = a.astimezone(tz=datetime.timezone.utc)

    Note: This issue is likely related to #81708

  8. ItsPadar commented on Dec 5, 2024

    @ItsPadar

    This issue is present on Python 3.12.7 on Windows 10 32bit and is causing me issues between production and development enviroments

  9. StanFromIreland commented on Mar 9, 2025

    @StanFromIreland
    Member

    Duplicates: #94757, #81708

  10. StanFromIreland commented on Mar 13, 2025

    @StanFromIreland
    Member

    @picnixz Maybe you could clean this up (since you seem to like triaging ;-) and decide which one should stay (at least please do add the os-windows labels, this project really needs some triaging :-( and unfortunately there is no way for most people to help with that) ?

    They are all because we use localtime_s

    The time_t value sourceTime represents the seconds elapsed since midnight (00:00:00), January 1, 1970, UTC.

    _localtime64_s, which uses the __time64_t structure, allows dates to be expressed up through 23:59:59, January 18, 3001,

  11. added
    stdlibStandard Library Python modules in the Lib/ directory
    on Mar 30, 2025
  12. picnixz commented on Mar 30, 2025

    @picnixz
    Member

    I'll close this one as a duplicate of #81708 (as this is about being close to the EPOCH in some sense).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    OS-windowsextension-modulesC modules in the Modules dirstdlibStandard Library Python modules in the Lib/ directorytype-bugAn unexpected behavior, bug, or error

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions