Hacker News Reader

Comment by mholt | Hacker News Reader

Yesterday while writing code to parse MP4 metadata, I learned that MP4 uses an epoch from the year 1904. (I was suspicious when I saw the timestamp start with a 3).

Turns out there's lots of epochs, and the Unix epoch doesn't have any "rationale" according to Wikipedia: https://en.wikipedia.org/wiki/Epoch_(computing)#Notable_epoc...

For example, Ingenuity helicopter counts from 2000.

View on HN

Early versions of Unix moved the epoch quite frequently between various dates in the 1960s and 1970s. Version 6 finally "settled" it on 1970 and everyone has just gone with that ever since.

It's somewhat arbitrary, but by making it a signed integer, Dennis Ritchie figured it was good enough to represent dates spanning his entire life time. He probably thought Unix's life time would be significantly shorter rather than outliving him.

I thought it was settled in Version 4. Compare:

https://www.tuhs.org/cgi-bin/utree.pl?file=V3/man/man2/time....

https://www.tuhs.org/cgi-bin/utree.pl?file=V4/man/man2/time....

EDIT: note that back then, it was a signed integer. Turns out that people wanted to be able to represent dates from before 1970 so we lost one bit.

My fuzzy memory had me thinking it was version 6, thanks for the correction!

> note that back then, it was a signed integer.

Still and always is. We'd be having a 2106 problem instead of 2038 if it was unsigned 32-bit.

sorry I meant it was an UNSIGNED integer back then

Lotus 1-2-3 used an epoch from 1900-01-01, but it had a bug where it considered all years divisible by 4 to be leap years.

When Excel came around, it needed to be compatible with 1-2-3, so it used the same date format, and to be compatible it considers 1900 to be a leap year.

Excel has two date systems, with either a 1900 or 1904 start date:

https://support.microsoft.com/en-us/office/date-systems-in-e...

The original Excel was for the Macintosh and had the 1904 date system, and was later brought to Windows where the 1900 date system was used.

Here’s a great story about the ongoing impact of those decisions. https://www.joelonsoftware.com/2006/06/16/my-first-billg-rev...

Perl counts from 1900, so the year 2000 was actually stored as 100. You'd get 2 digit years in the 1990s and suddenly 3 digit years after 2000. The solution was to arithmetically add 1900 to the year before rendering. Newer perl functions would handle that internally.

That's a direct translation of struct_tm from time.h.

     External declarations, as well as the tm structure definition, are
     contained in the <time.h> include file.  The tm structure includes at
     least the following fields:

           int tm_sec;     /∗ seconds (0 - 60) ∗/
           int tm_min;     /∗ minutes (0 - 59) ∗/
           int tm_hour;    /∗ hours (0 - 23) ∗/
           int tm_mday;    /∗ day of month (1 - 31) ∗/
           int tm_mon;     /∗ month of year (0 - 11) ∗/
           int tm_year;    /∗ year - 1900 ∗/
           int tm_wday;    /∗ day of week (Sunday = 0) ∗/
           int tm_yday;    /∗ day of year (0 - 365) ∗/
           int tm_isdst;   /∗ is summer time in effect? ∗/
           char ∗tm_zone;  /∗ abbreviation of timezone name ∗/
           long tm_gmtoff; /∗ offset from UTC in seconds ∗/

You'll note that tm_year is years since 1900.

While working support at SGI in the late 90s, got a number of support tickets (there was a woman who worked for a government department (NASA?) who was very good at finding them in doing their y2k checks) about dates showing up as `20100`.

Why does year 0000 have any rational? :)

Speaking of, when I think about it, it's amazing we've been keeping track days and years exactly for all this time (about 4000 years), with different calendar systems between civilizations. I guess astronomic event records (supernovae, comets, eclipses,...) serve as benchmarks so we can reconstruct relatively accurate timelines (the event you indirectly refer to has some uncertainty) from this cacophony.

When it comes to years, the most accurate unbroken timelines are based on tree rings (and similar, such as annual layers of sediments). The longest, the Hohenheim Tree Ring Timeline (Central European pine) goes back to 10,461 BC, and researchers hope to extend it another 2,000 years back.

Interestingly, there is no year 0

in the Gregorian calendar. Some other calendar systems do have a year zero. ISO 8601 (the time/data standard) does include a year zero, which maps to 1 BC.

This is one of the reasons why you shouldn't use an int32 to represent dates/date-time in text-based APIs unless you have a very good reason to (and I'd argue that you shouldn't be using a text-based API in many of those cases).

Reply on news.ycombinator.com