Why Does My Phone Think Its 1969?
Understanding a software bug ready-made for the Americas
Have you ever seen the date “December 31, 1969" pop up on some application or device, and it made no sense in context? I wasn’t even born in 1969, let alone texting my Grandmother, so what gives?
It must be a software bug of some sort, but it still feels like a pretty random date to occur so often, for so many people. Why the last day of a random year like 1969? January 1st, year zero, or 1900, or even 2000 might be logical, but 12/31/1969 seems bizarre.
There are a couple of things going on here. The first is that your application failed to retrieve a date, but still wants to display something. The second is that you are trying to view a date localized for people living west of standard time, and east of The International Date Line.
Dates and times are a tricky thing to record accurately. To achieve this, we smooth over the 24 hour day and 365 day year with manual adjustments. We use leap days, leap seconds, and the observations of satellites to reorient our calendar to match where the earth actually is in relation to the sun, down to the millisecond.
While this system of adjustments is vital to humans looking to keep a schedule, it can make designing a system of record for dates and times a struggle. Our standard time format is often ambiguous, updated manually, location specific, and uses strange, uneven units. Computers, and the software engineers writing code for them, needed a simpler date time format, and Unix time was an ideal candidate.
What Is Unix Time?
Most software uses some variant of what is called Unix time, which is simply the number of seconds that have passed since January 1, 1970, 12:00:00AM. One minute from this time would be represented as “60”, one thousand seconds from this time would be represented as “1000”, and so on.*
Unix is a series of operating systems built by Bell Labs, first released publicly in 1972. Unix time was developed as the system’s method of storing dates and times in a simple, portable, and reproducible manner. Although dozens of time formats have since come and gone for various computer architectures and operating systems, the popularity of the Unix platform itself led to Unix time as the dominant format by the late 80's.
“But wait!” you say, “I don’t see that it’s 1,686,673,276 when I check the time on my phone, I see that it’s 12:21PM. And anyways, what does any of this have to do with the December 31st bug?”
You may not see 1,686,673,276, but your phone sure does. In the background it takes that sane, simple number, and converts it into something humans can read, like Tuesday, 13 June 2023 16:21:16 PM, or even just 12:21 PM (in your local time zone).
So, what happens if you attempted to convert an a Unix timestamp of 0, or an empty timestamp value a similar non-valid value, to something human readable? For non numeric values, a lot of programming languages would treat this value as 0 for the purposes of conversion. For 0, the human readable format would be Thursday, January 1, 1970 12:00:00 AM.
That all makes sense, but why then, do you always see the prior day, rather than January 1, 1970? You can’t have a timestamp below zero, right?
Time Zones
You can’t have a timestamp below zero, but zero in the GMT time zone is not the same as zero in the rest of the world. Because your device accounts for your local time zone, you will see December 31, 1969 if you are to the west of UTC and east of the international date line. That is to say, everyone in the Americas (and Greenland) will see this date if there is an issue getting the actual date and time the application requested.
Side note: often times websites default to showing you the time of events in the time zone of the web server sending you content. This is why even as someone as far east as Japan or New Zealand might run into a 12/31/1969 date if the content they are receiving comes from abroad.
I hope this helped explain this occasional little quirk you may notice from time to time when viewing a bugged date and/or time.
References & Resources
Addendum:
* Unix time hasn’t actually been this simple in implementation since a major specification change, and this original implementation is now typically called POSIX time. Unix time now includes the manual addition of ambiguous leap seconds to maintain alignment with UTC. This appears to be the most current definition of Unix Time.
