# Mathematica cannot seem to properly handle times in the 1 hour before clocks go back

Using Chicago as an example;

According to the current rules for applying daylight saving time, at 02:00:00 on the first Sunday of November, clocks in Chicago go back 1 hour (from Central Daylight Time CDT to Central Standard Time CST).

In 2007, this transition occurred on the 4th of November. So that means, at 02:00:00 CDT on this date, clocks switched to 01:00:00 CST.

In[37]:= tzChicago = Entity["TimeZone", "America/Chicago"]

Out[37]= Entity["TimeZone", "America/Chicago"]


Let's try and construct DateObjects 1 second before 01:00:00 and at 01:00:00. (I cannot specify whether the latter is CDT or CST, but Mathematica should be able to handle it through the timezone specification.)

In[351]:= do005959CST =
DateObject[{2007, 11, 4, 0, 59, 59}, TimeZone -> tzChicago]

Out[351]= DateObject[{2007, 11, 4, 0, 59,
59}, "Instant", "Gregorian", "America/Chicago"]

In[352]:= do010000CST =
DateObject[{2007, 11, 4, 1, 0, 0.}, TimeZone -> tzChicago]

Out[352]= DateObject[{2007, 11, 4, 1, 0,
0.}, "Instant", "Gregorian", "America/Chicago"]


Notice, however, that Mathematica automatically assumes the latter time is CST, not CDT. But that means there is no way I can specify a time between 01:00:00 CDT and 02:00:00 CDT (a real interval of time that will be experienced by people living in Chicago, at the end of which, the clocks will be put back an hour). Any time given to Mathematica in this interval is automatically interpreted as CST, i.e. after the clocks have been put back.

I tried using an explicit timezone shift from GMT, which produces mixed results.

In[354]:= DateObject[{2007, 11, 4, 1, 0, 0.}, TimeZone -> -5]

Out[354]= DateObject[{2007, 11, 4, 1, 0,
0.}, "Instant", "Gregorian", -5.]

In[355]:= DateDifference[
DateObject[{2007, 11, 4, 0, 59, 59}, "Instant", "Gregorian",
"America/Chicago"],
DateObject[{2007, 11, 4, 1, 0, 0.}, "Instant",
"Gregorian", -5.], "Seconds"]

Out[355]= Quantity[1., "Seconds"]


So this looks correct. I appear to have managed to specify a time in the last hour of Chicago DST. But then this produces the following inconsistent result.

In[356]:= TimeZoneConvert[
DateObject[{2007, 11, 4, 1, 0, 0.}, "Instant",
"Gregorian", -5.], tzChicago]

Out[356]= DateObject[{2007, 11, 4, 1, 0,
0.}, "Instant", "Gregorian", "America/Chicago"]

In[357]:= DateDifference[
DateObject[{2007, 11, 4, 0, 59, 59}, "Instant", "Gregorian",
"America/Chicago"],
DateObject[{2007, 11, 4, 1, 0, 0.}, "Instant", "Gregorian",
"America/Chicago"], "Seconds"]

Out[357]= Quantity[3601., "Seconds"]


The application of TimeZoneConvert should return a point in time which is physically simultaneous with the input, yet we've now shifted an hour. Is this a bug or am I missing something?

• Although the results of this code is best put in an image format, it would be helpful to have the code as it is easily copy & paste-able. If you can, please, provide such code for future users & those who wish to answer this question? Feb 6, 2021 at 8:48
• Have added the code as requested. Feb 6, 2021 at 13:08
• Have you reported this? Feb 8, 2021 at 6:04
• Yes. Will report back if I hear anything. In the meantime the only workaround I can see is to use hard-coded timezone shifts (i.e. versus GMT) and avoid the use of timezone entities and strings. Feb 8, 2021 at 13:29
• Got an acknowledgement from Wolfram. Looks like it has been accepted as an issue and has been forwarded to the developers. Feb 11, 2021 at 13:36

I think this looks like a bug, though I have no authority to declare it. In particular, this looks like a hot mess:

That's the following:

tz = Entity["TimeZone", "America/Chicago"]

With[{t = DateObject[{2007, 11, 4, 1, 0, 0}, TimeZone -> tz]},
{t, UnixTime[t]}]

{ DateObject[{2007, 11, 4, 1, 0, 0}, "Instant", "Gregorian", "America/Chicago"], 1194159600 }

With[{t =
DateObject[{2007, 11, 4, 1, 0, 0}, TimeZone -> tz] -
Quantity[1, "Seconds"]},
{t, UnixTime[t]}]

{ DateObject[{2007, 11, 4, 0, 59, 59.}, "Instant", "Gregorian", "America/Chicago"], 1194155999 }


Subtracting one second has caused a change of 3601 seconds in UnixTime space. I have so far been unable to imagine a possible world where this is correct. But this does rather suggest that date/time handling is terminally borked in Mathematica, which I struggle to believe.

• Oh boy, this is pretty broken. If you instead travel forward in time 1 second, from 00:59:59 to 01:00:00 you get to be in both CDT & 3601 seconds ahead in UnixTime space! Feb 6, 2021 at 9:07