Why do date ranges in computing start at ancient periods?

Question

Reading the Wikipedia article for HFS+, I noticed the allowable date range is January 1, 1904 – February 6, 2040. Likewise, the range for NTFS is 1 January 1601 – 28 May 60056. In my mind, this is ridiculous to think about as I can't think of any cases where a file would need to have a modified/created at date set in the 1600s or 1900s. I can understand the Unix timestamp epoch since it would be reasonable to have a file created/modified in the 70s, 80s, etc, but it just seems illogical to have the epoch of those timestamps to be set so far back in the past.

Answer 1

It's not just NTFS; Windows internal timekeeping is done using the same time format and with the same start of epoch.

They knew they wanted a 64-bit binary time value, because the original Unix 32-bit value was already known to be a dead end (those counters will wrap in 2038), and 64-bit time values had already been used in VMS. 64 bits gives the ability to reckon about 18 billion billion different time values. Well, actually, only 9 billion billion because time values with the high bit set have a different meaning in Windows (as they do in VMS). So we really have "only" 63 bits for counting date and time of day.

Whereas the 32-bit Unix time only counted seconds, Windows timestamps reckon in increments of 100 nanoseconds. So a time value of 1 means 100 ns past midnight on January 1, 1601.

But why pick such a "historical" date?

Well, one, it does make day-of-week and similar calculations a bit easier, as that was the first year of the earliest 400-year cycle that included electronic computers of any sort. There is some very authoritative support for that reason.

However, I have to opine that in the context of modern computing the additional compute power needed to cope with a different starting year would be pretty small in context.

January 1 1601 also happens to be the date from which ANSI dates are counted. So the "Windows date" is the same day number as the "ANSI date", which makes things a trifle easier in various places.

It's also been standardized as "year 1" of the Gregorian calendar (even though that calendar was not adopted everywhere at that time).

For a practical, working reason, though, consider: This date/time format allows historical date/times to be represented in e.g. data bases right alongside present-day ones, using the same format. A genealogical data base, for example, can thus store your ancestors' birth and death dates going back 400+ years, which is far longer than most such records exist in reliable form.

There would have been no point extending this earlier, starting at say the year 1201 or even 1, because of the Julian-to-Gregorian calendar transition that began in some countries in 1582 and continued to as late as 1926, depending on which country you were in. All dates recorded in ANSI time format and, by extension, in Windows "binary" time format are assumed to be Gregorian calendar.

btw, VMS uses a similar scheme but its base time is 17 Nov 1858. This was a standard picked by the Smithsonian Astrophysical Observatory as a "base date" for satellite tracking; this was related to astronomers' earlier use of the original Julian Day scheme, which counts days since noon, January 1, 4713 B.C. On this scheme, 17 Nov 1858 comes out to Modified Julian Day number 2,400,000. By using the MJD instead of the JD they were able to fit contemporary dates into just 18 bits, which was an important feat at the time. See this article from VMS Engineering for details.

Answer 2

Dates (and their format specification on the bit level) are not only used to label files, but also for calculation and in many other places. A historician might want to have dates from the 17th or 18th century in his Excel columns, for example; or an astronomer calculate planetary alignments in these periods.

Even if the amount of people thathave a use from it is small, the loss is negligent - it doesn't matter much if you can use this format for 100 or 5000 or 60000 years; it will probably not survive the next 50 years.

Answer 3

When examined in isolation the wide time stamp range of NTFS may seem illogical. But when you look at the big picture it is completely logical.

One of the things an operating system does is provide a set of functions that most programs will need. This allows programmers to concentrate on their programs instead of wasting time rewriting these common functions for each program. Any operating system that does not provide these functions is unlikely to be successful. Windows and Linux provide hundreds of such functions.

Windows includes a series of functions for representing and working with dates and times. For maximum usefulness this covers as wide a range of dates as is reasonably possible. Many programs use these functions for a wide variety of purposes.

The NTFS file system was released as part of the NT platform. Like any modern file system it needed some way of storing file date stamps. Logically the designers chose to use the same system as the one provided to applications. This makes things simpler for developers. Of course the date range is much wider than needed for date stamps but it costs nothing and causes no problems. Using a different system with a more restricted range of dates for date stamps would have been illogical.