Value of "tm_gmtoff" is invalid when setting time far in the future on Windows

[Delgan]

Bug report

Bug description:

Hi.

On Windows 11, when changing the system time to the year 2040 (through OS settings), the value of struct_time.tm_gmtoff becomes unreliable.

The following code:

from time import localtime
from datetime import datetime

now = datetime.now()
timestamp = now.timestamp()
local = localtime(timestamp)

print(f"tm_gmtoff: {local.tm_gmtoff}")

Outputs on my computer:

tm_gmtoff: -4294963696

My real offset from UTC is +3600 seconds. It's worth noting that -2**32 + 3600 = -4294963696.

I noted the following code can be used as a workaround, producing the expected 3600 value despite the time shift:

from datetime import datetime, timezone

timestamp = now = datetime.now().timestamp()
utc_naive = datetime.fromtimestamp(timestamp, tz=timezone.utc).replace(tzinfo=None)
offset = datetime.fromtimestamp(timestamp) - utc_naive
seconds = offset.total_seconds()

print(f"offset: {seconds}")

As a more concrete real-world scenario, clock shifting can occur accidentally due to battery issues (as per the user who originally reported this bug to me).

I don't know if this should be considered a bug for CPython. If not, could we at least add a note about this edge case in the documentation?

CPython versions tested on:

3.13

Operating systems tested on:

Windows

[Delgan]

Closing, sorry, it seems already documented. Year 2040 falls out of the range supported by localtime:

localtime() may raise OverflowError, if the timestamp is outside 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 between 1970 and 2038.