Why [Open]VMS regards November 17, 1858 as the beginning of time...

The modified Julian date adopted by SAO (Smithsonian Astrophysical Observatory) for satellite tracking is Julian Day 2400000, which turns out to be November 17, 1858.

SAO started tracking satellites with an 8K (nonvirtual) 36-bit IBM 704 in 1957 when Sputnik went into orbit. The Julian day was 2435839 on January 1, 1957. This is 11225377 octal, which was too big to fit into an 18-bit field. With only 8K of memory, the 14 bits left over by keeping the Julian date in its own 36-bit word would have been wasted. They also needed the fraction of the current day (for which 18 bits gave enough accuracy), so it was decided to keep the number of days in the left 18 bits and the fraction of a day in the right 18 bits of one word.

Eighteen bits allows the truncated Julian day (the SAO day) to grow as large as 262143, which from November 17, 1858, allowed for 7 centuries. Possibly, the date could only grow as large as 131071 (using 17 bits), but this still covers 3 centuries and leaves the possibility of representing negative time. The 1858 date preceded the oldest star catalogue in use at SAO, which also avoided having to use negative time in any of the satellite tracking calculations.

As a tangent to a nearby discussion ...

1752 or 1753 are interesting choices of epoch, but also 1858 is interesting...

via the article The stories behind 12 computer system reference dates

Humour, but https://xkcd.com/927/ is always relevant.

For ease of reference, from the linked article (which has much more detail):

January 1, 1: used by .NET, Go (start of the Gregorian calendar)

In order to ensure against losing revenue it was decided by the British Treasury that the tax year, which started on March 25 1752, would be of the usual length (365 days) and therefore it would end on April 4, the following tax year beginning on April 5.

I think I'm with BDD on this: use time-since-epoch for as long as you possibly can, until the last minute(!) when you need to convert to human format for human purposes - at which point timezones, leap years, leap seconds, international date lines, names for days of weeks, choices about week numbers, can all come into play.

Interesting aside: supposedly all versions of MS Windows based on the NT kernel have their epoch in the year 1600. However, I've discovered that if I set the last write date of a file on one of my Linux servers to midnight January 1, 1980 or earlier and then display the directory in Windows (via Samba) no date and time is displayed for the file entry. I'm don't think this is a Linux or Samba thing.

According to the article that BigEd linked MS-DOS uses 1/1/80 as its epoch, so I'm guessing the same limitation made its way into the SMB protocol as well.

I think I'm with BDD on this: use time-since-epoch for as long as you possibly can, until the last minute(!) when you need to convert to human format for human purposes - at which point timezones, leap years, leap seconds, international date lines, names for days of weeks, choices about week numbers, can all come into play.