Why Does Your App Show 1970‑01‑01? Uncovering the Unix Timestamp Origin

1970‑01‑01 is familiar to developers because many systems show that date when time handling is incorrect.

You can reproduce this behavior with simple Java code:

<code>Date date = new Date(0);
System.out.println(date);</code>

The printed result is:

<code>Thu Jan 01 08:00:00 CST 1970</code>

According to the Java

Date

constructor documentation, the argument is a millisecond offset from the epoch; a value of 0 corresponds to 1970‑01‑01 00:00:00 GMT.

The concept of a Unix timestamp originates from the early Unix operating system. In August 1969, Ken Thompson at Bell Labs began developing Unix on a PDP‑7 using the B language, later evolving to C and releasing a new Unix version in 1971.

To represent time on Unix, a timestamp was defined as the number of seconds elapsed since a chosen "epoch". The original epoch was set to 1971‑01‑01, and the timestamp changed every 1/60 of a second.

Because early computers were 32‑bit, the maximum signed integer (2^31‑1) limited the usable range. Using the original 1/60‑second granularity, the timestamp could cover only about 828.5 days.

Developers later adjusted the granularity to one second per increment, extending the range by 60× to roughly 136 years. Consequently, the epoch was shifted back to 1970‑01‑01, a change adopted by subsequent programming languages.

Thus, the Unix timestamp now counts the total seconds elapsed since 1970‑01‑01 00:00:00 GMT.

Time zones affect the displayed local time. For example, China’s UTC+8 offset makes 1970‑01‑01 00:00:00 GMT appear as 1970‑01‑01 08:00:00 locally.

A notable bug occurred on iOS devices (iOS 8.0 to 9.3 beta 3) with 64‑bit processors: setting the device clock to 1970‑01‑01 00:00:00 (UTC) caused a negative timestamp, leading to a “brick” condition.