Search code examples
datetimeansi-c

What is the significance of January 1, 1601?

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:

Solution

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

    time.c

        Absolute LARGE_INTEGER in NT is represented by a 64-bit large integer accurate
    to 100ns resolution. The basis for NT time is the start of 1601 which
    was chosen because it is the start of a new quadricentury.  Some facts
    to note are:

    o At 100ns resolution 32 bits is good for about 429 seconds (or 7 minutes)

    o At 100ns resolution a large integer (i.e., 63 bits) is good for
      about 29,247 years, or around 10,682,247 days.

    o At 1 second resolution 31 bits is good for about 68 years

    o At 1 second resolution 32 bits is good for about 136 years