What happened on March 16th 1984?

Question

I am trying to figure out what's special about March 16th, 1984. On a virtual machine I am using (nothing special about it), Python (as well as PyPy) crashes when trying to use mktime with what seems to be a perfectly reasonable time struct.

$ pypy
Python 2.7.3 (f66246c46ca30b26a5c73e4cc95dd6235c966b8f, Jul 30 2013, 09:27:06)
[PyPy 2.0.2 with GCC 4.4.7 20120313 (Red Hat 4.4.7-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>> import time
>>>> time.mktime((1984,3,16,0,0,0,0,0,0))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: mktime argument out of range
>>>> time.mktime((1984,3,15,0,0,0,0,0,0))
448156800.0
>>>> time.mktime((1984,3,17,0,0,0,0,0,0))
448326000.0
>>>> time.mktime((1984,3,16,0,0,0,0,0,0))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: mktime argument out of range
>>>>

Why and what can be done to avoid this issue?

Although the problem does happen every time on this VM, I could not make it occur on any other.

Strange. Doesn't give a problem on my machine (Mac OS, Python 2.7). — Floris, Sep 23 '13 at 02:33
I thought it might be leap seconds, but none were added in 1984 (on any date) see http://en.wikipedia.org/wiki/Leap_second . I am suspecting a bug in your version of Python... — Floris, Sep 23 '13 at 02:37
Nothing to add other than that I don't have a problem either. Very odd. — verbsintransit, Sep 23 '13 at 02:41
It was an exceptionally [ordinary day](http://www.historyorb.com/date/1984/march/16) ;-) — Tim Peters, Sep 23 '13 at 02:41
http://stackoverflow.com/questions/2518706/python-mktime-overflow-error — Shashank, Sep 23 '13 at 02:44
Can't say for sure. My program deals with several dates and this is the only one for which it happened. — Benoît, Sep 23 '13 at 02:52
@ShashankGupta : indeed it boils down to system issue. "date -d 03/16/1984" returns "invalid date. Still weird, though. — Benoît, Sep 23 '13 at 02:54
@falsetru : $ date --> "lun. sept. 23 03:58:07 WEST 2013" so WEST :) — Benoît, Sep 23 '13 at 03:00
I think it's pretty clear, from both your own testing and other people's comments, that the VM in question (much more so than either CPython or PyPy) is worth investigating for bugs. — John Y, Sep 23 '13 at 03:05
As to the question "what can be done to avoid this issue?" the answer is also exceedingly clear: Don't use that particular VM! — John Y, Sep 23 '13 at 03:06
@JohnY: I guess you are right but i have no clue as to where to start the investigation ! — Benoît, Sep 23 '13 at 03:18
Well, one first step would be to tell people what VM you are using, and adjust the tags of this question accordingly. Be as specific as possible. When you say there is "nothing special about it", well, we all know that is incorrect. Clearly there *is* something special, and wrong, about this VM. — John Y, Sep 23 '13 at 11:28

Damien_The_Unbeliever · Answer 1 · 2013-09-23T12:09:42.563

7

Your machine thinks that there was a daylight savings transition between midnight on 15th March 1984 and midnight on 17th March 1984, given that the difference between 448326000.0 and 448156800.0 is 47 hours, not 48.

But so far as I can tell, no such transition occurred on that day in France. And I'm not sure how you fix your OS's interpretation of historic daylight savings transitions.

edited Sep 23 '13 at 12:09

answered Sep 23 '13 at 06:01

Damien_The_Unbeliever

234,701
27
340
448

Changing the timezone (which was wrongfully set to Casablanca) solved the issue... or translated to another unknown date, who knows ! – Benoît Sep 23 '13 at 11:38
Wow, someone cared enough to actually inspect the results and *do* something with them! Nice! That alone is worth an upvote from me, even though it's not really a solution to the OP's problem. Hopefully it will at least provide some clue that will eventually lead to the real answer. In that spirit, I would like to suggest to OP to try narrowing down the timeframe. Is all of 1984-03-16 screwed up, or is it a particular hour? The daylight saving thing is a nice guess, but incredibly weird (by U.S. standards) because that date was a Friday, and our DST always starts/ends on Sunday. – John Y Sep 23 '13 at 11:38
1

Ah, OP posted a resolution (though not exactly solving the mystery) while I was typing my comment. I guess kudos to @falsetru as well, since he did ask about the time zone. – John Y Sep 23 '13 at 11:44

John Y · Accepted Answer · 2013-09-23T12:02:46.623

Aha! Mystery solved (since OP finally figured out the time zone "at fault"). I found this:

http://www.timeanddate.com/worldclock/timezone.html?n=60&syear=1980

1980    No time changes  
1981    No time changes  
1982    No time changes  
1983    No time changes  
1984    Time zone change on Friday, March 16, 1984 at 1:00:00 AM     
1985    Time zone change on Tuesday, December 31, 1985 at 11:00:00 PM    
1986    No time changes  
1987    No time changes  
1988    No time changes  
1989    No time changes

So, I guess the answer to "What happened on March 16th 1984" is that Casablanca changed its time at 1:00 AM that day. :)

And technically, it jumped immediately from midnight to 1:00 AM, so probably all times starting at 00:00 and just before 01:00 will produce the same error. That is, my guess is that time.mktime((1984,3,16,1,0,0,0,0,0)) and greater will work, but for example, time.mktime((1984,3,16,0,59,0,0,0,0)) will not.

So, there was never a midnight on the night between 15th and 16th March (what would have been midnight instantly became 1am), and that's why that specific time cannot be constructed. — Damien_The_Unbeliever, Sep 23 '13 at 11:56
Y'know, if this question had been tagged `timezone` from the beginning (and especially if it did not have the `python` tag, probably), then Jon Skeet would have been all over this. See the miraculous-seeming answer here: http://stackoverflow.com/questions/6841333/why-is-subtracting-these-two-times-in-1927-giving-a-strange-result — John Y, Sep 23 '13 at 13:41

What happened on March 16th 1984?

2 Answers2