4 ms·

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

by mholt 4y ago

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_epoch_dates_in_computing https://en.wikipedia.org/wiki/Epoch_(computing)#Notable_epoc... For example, Ingenuity helicopter counts from 2000.

chungy 4y ago
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.
- marvy 4y ago
  I thought it was settled in Version 4. Compare: https://www.tuhs.org/cgi-bin/utree.pl?file=V3/man/man2/time.2 https://www.tuhs.org/cgi-bin/utree.pl?file=V3/man/man2/time.... vs https://www.tuhs.org/cgi-bin/utree.pl?file=V4/man/man2/time.2 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.
  - chungy 4y ago
    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.
    - marvy 4y ago
      sorry I meant it was an UNSIGNED integer back then
aidenn0 4y ago
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.
- zdw 4y ago
  Excel has two date systems, with either a 1900 or 1904 start date: https://support.microsoft.com/en-us/office/date-systems-in-excel-e7fe7167-48a9-4b96-bb53-5612a800b487 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.
- cookingrobot 4y ago
  Here’s a great story about the ongoing impact of those decisions. https://www.joelonsoftware.com/2006/06/16/my-first-billg-review/ https://www.joelonsoftware.com/2006/06/16/my-first-billg-rev...
roflyear 4y ago
Why does year 0000 have any rational? :)
- astrobe_ 4y ago
  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.
  - Archelaos 4y ago
    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.
- tiagod 4y ago
  Interestingly, there is no year 0
  - technothrasher 4y ago
    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.
bluesmoon 4y ago
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.
- shagie 4y ago
  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`.
radicalbyte 4y ago
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).

by mholt 4y ago

chungy 4y ago

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.

marvy 4y ago
I thought it was settled in Version 4. Compare: https://www.tuhs.org/cgi-bin/utree.pl?file=V3/man/man2/time.2 https://www.tuhs.org/cgi-bin/utree.pl?file=V3/man/man2/time.... vs https://www.tuhs.org/cgi-bin/utree.pl?file=V4/man/man2/time.2 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.
- chungy 4y ago
  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.
  - marvy 4y ago
    sorry I meant it was an UNSIGNED integer back then

aidenn0 4y ago

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.

zdw 4y ago
Excel has two date systems, with either a 1900 or 1904 start date: https://support.microsoft.com/en-us/office/date-systems-in-excel-e7fe7167-48a9-4b96-bb53-5612a800b487 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.
cookingrobot 4y ago
Here’s a great story about the ongoing impact of those decisions. https://www.joelonsoftware.com/2006/06/16/my-first-billg-review/ https://www.joelonsoftware.com/2006/06/16/my-first-billg-rev...

roflyear 4y ago

Why does year 0000 have any rational? :)

astrobe_ 4y ago
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.
- Archelaos 4y ago
  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.
tiagod 4y ago
Interestingly, there is no year 0
- technothrasher 4y ago
  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.

bluesmoon 4y ago

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.

shagie 4y ago
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`.

radicalbyte 4y ago

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).