54

This structure is a 64-bit value representing the number
of 100-nanosecond intervals since January 1, 1601.

Reference: http://msdn.microsoft.com/en-us/library/aa915351

Why it is set "since 1601"? Why not unix time 1970 or even 2000? What can I do with the compatibility of so distant in time dates?

Answering to myself.

The ANSI Date defines January 1, 1601 as day 1, and is used as the origin of COBOL integer dates. This epoch is the beginning of the previous 400-year cycle of leap years in the Gregorian calendar, which ended with the year 2000. as you can find in wikipedia under Julian_day entry.

Further:

Thomas Dickey
  • 51,086
  • 7
  • 70
  • 105
zakrzak
  • 543
  • 1
  • 4
  • 7

4 Answers4

61

Because 1/1/1601 was the start of the epoch.

Take it from Raymond Chen:

Why is the Win32 epoch January 1, 1601?

The FILETIME structure records time in the form of 100-nanosecond intervals since January 1, 1601. Why was that date chosen?

The Gregorian calendar operates on a 400-year cycle, and 1601 is the first year of the cycle that was active at the time Windows NT was being designed. In other words, it was chosen to make the math come out nicely.

I actually have the email from Dave Cutler confirming this.

Bonus Chatter

RFC4122 UUIDs also measure 100ns ticks, but they start at 10/15/1582 (as opposed to FILETIME's 1/1/1601:

Date                    Ticks               Uuid Epoch ticks
----------------------  ------------------  ------------------
1582-10-15              -5748192000000000   0                    Start of uuid epoch
1601-01-01              0                   0x00146BF33E42C000   Start of Windows epoch
1899-12-30              0x014F35A9A90CC000  0x0163A19CE74F8000   Lotus 123/Excel/Access/COM zero date
1900-01-01              0x014F373BFDE04000  0x0163A32F3C230000   SQL Server zero date
1970-01-01              0x019DB1DED53E8000  0x01B21DD213814000   Unix epoch timestamp
2000-01-01              0x01BF53EB256D4000  0x01D3BFDE63B00000
2010-01-01              0x01CA8A755C6E0000  0x01DEF6689AB0C000
2020-01-01              0x01D5C03669050000  0x01EA2C29A747C000

//FILETIME eras
1972-01-21 11:43:51 PM  0x01A0000000000000  0x01B46BF33E42C000   Start of 0x01A era
1986-04-30 11:43:13 AM  0x01B0000000000000  0x01C46BF33E42C000   Start of 0x01B era
2000-08-06 11:42:36 PM  0x01C0000000000000  0x01D46BF33E42C000   Start of 0x01C era
2014-11-14 11:41:59 AM  0x01D0000000000000  0x01E46BF33E42C000   Start of 0x01D era
2029-02-20 11:41:22 PM  0x01E0000000000000  0x01F46BF33E42C000   Start of 0x01E era
2043-05-31 11:40:44 AM  0x01F0000000000000  0x02046BF33E42C000   Start of 0x01F era

//UUID eras
1968-02-11 11:43:13 AM  0x019B940CC1BD4000  0x01B0000000000000   Start of uuid 0x01B era
1982-05-20 11:42:36 PM  0x01AB940CC1BD4000  0x01C0000000000000   Start of uuid 0x01C era
1996-08-27 11:41:59 AM  0x01BB940CC1BD4000  0x01D0000000000000   Start of uuid 0x01D era
2010-12-04 11:41:22 PM  0x01CB940CC1BD4000  0x01E0000000000000   Start of uuid 0x01E era
2025-03-13 11:40:44 AM  0x01DB940CC1BD4000  0x01F0000000000000   Start of uuid 0x01F era

Bonus Chatter

Excel uses a zero date of 12/30/1899 in order to be bug-for-bug compatible with Lotus 1-2-3. Which is also why Excel considers February 1900 to be a leap year (because the Lotus 1-2-3 guys thought it was). Which is why it's also impossible to represent dates before March 1, 1900 in Excel.

Community
  • 1
  • 1
Ian Boyd
  • 246,734
  • 253
  • 869
  • 1,219
  • 1
    In a global forum it makes a lot more sense to use unambiguous date formats, per the RFC, such as Oct 15, 1582. – RobG Jun 14 '21 at 10:15
  • @RobG As soon as Microsoft invents that time machine, they'll go back and implement your idea. Except it's a poor idea; since 1/1/1600 has benefits. It's like Unix deciding that 1/1/1970 was a valid zero date for anything. – Ian Boyd Jun 14 '21 at 14:15
  • I was commenting on the date format, not the date itself. Yes, 1 Jan 1970 is a random date too. Various MS applications use 1 Jan 1900 (e.g. Excel I think). :-) – RobG Jun 14 '21 at 20:45
  • BTW, great reference to David Cutler, I figured NT might have used that from his links to VAX/VMS. – RobG Jun 14 '21 at 23:04
  • @RobG Oh, i see what you mean. I chose to use an unambiguous date format, per ISO. The nice thing about standards is that there are so many to choose from. But in a global forum, using *"Oct"* assumes you understand english, and it's abbreviations for english month names. For our friends in Canada you would need to say `ᐅᑐᐱ 15, 1582` – Ian Boyd Oct 21 '21 at 19:44
11

Well, 1 January 1601 was the first day of the 17th Century. And pendulum clocks were invented in the 17th century, allowing time to be measured to 1 second accuracy1. So (in theory) there might be references in extant literature from that period to timepoints measured with that accuracy.

But in reality the choice is arbitrary. There has to be an "epoch", and provided

  1. the epoch is far enough back that "negative time" values are rare, and

  2. the wrap-around time is far enough in the future to be a few generations away,

any choice will do.

But hey, if it worries you that much, send a letter to Steve Balmer2.

I'm inclined to believe Ian Boyd's answer, given the claimed source. And the reason therein is that it makes the math easier (for Gregorian leap year calculation). However, given how tiny that simplification is, and how weak the reasoning behind it, the choice is (IMO) essentially arbitrary. (Not that I'm saying it is wrong ...)

1 - OK ... probably not that accurate.

2 - Or Satya Nadella.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • But what for this structure cover whole 17th, 18th and 19th century. In 100-nanosecond intervals. – zakrzak Jun 01 '12 at 12:08
  • 2
    So what? It is useful when you want to timestamp some event in the past. – Oleg V. Volkov Jun 01 '12 at 12:18
  • 1
    @Oleg -- insurance companies and governments are major users of COBOL. You could have a birthdate going back to 1900 for a living citizen, and would certainly keep records on deceased citizens who were born as far back as 1850. Its not uncommon to have 120 year leases on buildings, so a mortgage or policy on an existing lease would need to record start dates in the 1890s, any history would need dates much further back. – James Anderson Jun 14 '12 at 07:29
  • 1
    "*But in reality the choice is arbitrary.*". Exactly. There are any number of milestone dates that might be selected. Likely whoever first chose it just wanted a point far enough back in history that time values would likely always be positive, and not so far back as to exceed the maximum convenient integer size with a reasonable level of precision such as millisecond that also allowed a reasonable time into the future. Given the power of modern computers, they should have no issue with nanosecond accuracy back to the start of Earth history, and forward just as far. :-) – RobG Jun 14 '21 at 10:20
8

Its a pragmatic choice.

The modern western calendar was not consistent until 1752 when Britain (and its colonies) adopted the Gregorian calendar, which had been adopted in most of catholic Europe since 1582.

This is the modern calendar with leap years etc. to keep the 1st of January aligned with the winter solstice.

So why not start from 1st January 1752? Because the basic leap year rule "Its a leap year if the two digit year is divisible by four except if the four digit century is also divisible by four") established a 400 year cycle. The first full cycle starting on 1st January 1601, (at least in Rome).

The leap year and date calculations are painful enough without starting midway through a four hundred year cycle so 1600 is a pretty good start as long as you remeber that any dates before 1752 need to be qualified by a geographic location, as British dates were 10 days out of sync. with Roman dates by this time.

James Anderson
  • 27,109
  • 7
  • 50
  • 78
  • *This is the modern calendar with leap years etc. to keep the 1st of January aligned with the winter solstice.* Well, that failed as the northern hemisphere winter solstice usually occurs on 21 December. :-) – RobG Jun 14 '21 at 10:27
4

As has already been mentioned I think the popular answer is because the Gregorian calendar operates on a 400-year cycle, and 1601 is the first year of the cycle that was active at the time Windows NT was being designed.

January 1, 1601 is origin of COBOL integer dates.

It is also day 1 by ANSI date format.

And if you speculate further according to ISO8601 which is the format in which it is in, prior to 1583 time was based on the proleptic Gregorian calendar which has 366 days per year. Perhaps they just rounded up to the next century.

davidcondrey
  • 34,416
  • 17
  • 114
  • 136
  • Proleptic Gregorian calendar is no different from the standard Gregorian calendar, other than the fact that said calendar is being applied to dates before its epoch. – Chris Charabaruk Oct 17 '20 at 00:00