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.
4http://stackoverflow.com/questions/10849717/what-is-the-significance-of-january-1-1601 – Polygnome – 2017-03-20T01:12:33.080
2Its due to the 400 year cycle for leap intervals, and the modulo arithmetic involved in math surrounding leap cycles. It is the beginning of the first such period where digital files came to exist. – Frank Thomas – 2017-03-20T01:17:52.920
Its notable that ANSI adopted this same date for their stamps, so its used in the COBOL and other ANSI language specifications. Basically it makes a lot of math on the raw value is a whole lot easier if you can limit the number of recursions in terms of time adjustment cycles, by establishing a base that we haven't drifted too far from (in the grand scheme of things). If you have ever tried to write code to calculate the Date Easter Sunday will appear on, you will notice that the further back or forward you go, the longer and more complicated the formula required becomes. – Frank Thomas – 2017-03-20T02:30:03.507