Perhaps I am not using the libraries correctly, or perhaps there was some kind of standard change on December 15, 1901 concerning world wide time keeping. But I stumbled across this odd behavior while working on a time related application.
sydney = pytz.timezone("Australia/Sydney")
tokyo = pytz.timezone("Japan")
new_york = pytz.timezone("US/Eastern")
dt1 = datetime(1901, 12, 14)
dt2 = datetime(1901, 12, 15)
print("-" * 50)
print(sydney.localize(dt1).astimezone(pytz.UTC))
print(tokyo.localize(dt1).astimezone(pytz.UTC))
print(new_york.localize(dt1).astimezone(pytz.UTC))
print("-" * 50)
print(sydney.localize(dt2).astimezone(pytz.UTC))
print(tokyo.localize(dt2).astimezone(pytz.UTC))
print(new_york.localize(dt2).astimezone(pytz.UTC))
print("-" * 50)
I expected this code to tell me the UTC equivalent of the midnight times in these different time zones. What I found odd was that for older datetimes before Dec 1901 the results were not even falling on the hour but had minute components. After Dec 1901 it seems every conversion ended up being on the hour. Here is the output of the code above:
--------------------------------------------------
1901-12-13 13:55:00+00:00
1901-12-13 14:41:00+00:00
1901-12-14 05:00:00+00:00
--------------------------------------------------
1901-12-14 14:00:00+00:00
1901-12-14 15:00:00+00:00
1901-12-15 05:00:00+00:00
--------------------------------------------------
Wondering if I am not using a reliable technique or if this is actually correct due to some historical/political reason?
This seems to be related to the year 2038 problem, though I'm not sure how exactly. 1901-12-13 20:45:52 UTC is
2**31seconds before the Unix epoch, and if we look at that time for London, it's a minute off before.By the way, note that these examples were all already using standard time based on GMT by 1901. On the other hand, Portugal for example only adopted it as of 1912-01-01, so doesn't show the same behaviour.