Comment 9 for bug 1328600

So, I've spent quite some time looking at this problem today.

There are actually several, related problems here:

First, on 32 bit platforms, you cannot create a timedelta object with large values either. This fails:

python3 -c "import datetime; datetime.timedelta(2983579200)"

so the proposed fix for autopilot doesn't, in fact, fix anything.

Second, adding a timedelta to a datetime object takes into account the local timezone, including the DST. So, for example:

>>> def do_test(num_seconds):
... dt1 = datetime.fromtimestamp(num_seconds)
... dt2 = datetime.fromtimestamp(0) + timedelta(seconds=num_seconds)
... print("Timestamps are %s the same: %s %s" % ("" if dt1 == dt2 else "not", dt1, dt2))
...
>>> do_test(2222121600)
Timestamps are the same: 2040-06-01 12:00:00 2040-06-01 12:00:00
>>> do_test(2208988800)
Timestamps are not the same: 2040-01-01 13:00:00 2040-01-01 12:00:00

This has nothing to do with the year of the timestamp, but rather because in New Zealand (which is my current locale), Jan has DST applied, but June does not (or the other way around, whatever).

So, sadly, both approaches have problems:

* Using datetime.fromtimestamp (current implementation) breaks because datetime uses C libraries that, on a 32 bit system, won't work with timestamps that overflow an int (which will be 32 bits).

* Using datetime.timedelta for some reason applies DST adjustments, which is frankly dumb. I'd expect this to hold true all the time:

datetime.fromtimestamp(N) == datetime.fromtimestamp(0) + timedelta(seconds=N)

but it only evaluates to true in local winter months it seems.

So this needs more investigation, is my final verdict :)