Windows Time Formats: FILETIME, .NET Ticks, and the 1601 Epoch
Windows history left developers a shelf of look-alike formats: FILETIME and LDAP count 100-nanosecond ticks from 1601, .NET counts the same unit from year 1, WebKit times count microseconds from 1601, and Excel counts days from 1899. They look similar and mean different moments. Here is the family tree.
One ancestor: the FILETIME
Everything on this page descends from a single Win32 structure called
FILETIME: a 64-bit count of 100-nanosecond
intervals since January 1, 1601, 00:00:00 UTC.
Windows NT chose 1601 because the Gregorian calendar repeats on a 400-year
cycle, and 1601 is the start of a cycle — so a simple count of 100 ns
intervals can represent dates across the whole range without calendar
ambiguity. (The Unix epoch of 1970, by contrast, was chosen for convenience,
not calendar math.)
Because the representation is so useful, the same 1601-based count shows up all over the ecosystem under different names:
-
Win32
FILETIME— fromGetFileTime(), the registry, and NTFS metadata. -
Active Directory / LDAP attributes — values such as
pwdLastSet,accountExpires,lastLogon, andwhenChangedare FILETIME counts, exposed through theADsLargeIntegertype. PowerShell'sGet-ADUserprints them as 18-digit numbers. - Chrome / WebKit "epoch" times — browsers store some values (such as cookie expiry in WebKit-based engines) as microseconds since 1601, which is simply the FILETIME count divided by 10.
To convert any of these to Unix time, subtract the seconds between 1601 and
1970 — 11,644,473,600 seconds, or
116444736000000000 in 100 ns units.
The sibling that counts from year 1: .NET ticks
.NET uses the same 100-nanosecond unit but starts counting from
midnight on January 1, year 1 (0001-01-01), the start of
the proleptic Gregorian calendar. Every System.DateTime and
DateTimeOffset is built on this tick count, which is why
current .NET timestamps are ~18-digit numbers around
6.39 × 1017. The gap between year 1 and the Unix
epoch is 621355968000000000 ticks (exactly
62135596800000 milliseconds).
- Ticks → Unix ms:
ticks / 10_000 − 62135596800000. - Unix ms → Ticks:
(ms + 62135596800000) × 10_000.
The spreadsheet branch: Excel serial dates
Excel stores dates as OLE Automation (OADate) serial numbers: whole days since December 30, 1899, with the time of day in the fraction. Two historical quirks explain the odd epoch:
- Excel's date system began on January 1, 1900, but it treats 1900 as a leap year (it was not), so the serial number 60 is the fictional date February 29, 1900. To stay compatible with Lotus 1-2-3, Excel kept the bug and aligned its numbering so that modern dates match the OADate count that starts at zero on December 30, 1899.
- The practical consequence is that serial numbers count whole days since December 30, 1899, but dates before March 1, 1900 must be adjusted for the leap-year fiction — the Excel date converter handles that range correctly.
Other pre-1970 epochs in the family
Two more classic formats hang off the same tree but count from different roots:
-
Mac HFS+ counts whole seconds from January 1,
1904 (the classic Macintosh epoch) — offset
2082844800seconds from Unix time. It survives in forensic metadata, AppleDouble files, and vintage archives. Because it uses unsigned 32-bit seconds, it runs out on February 6, 2040. - NTP timestamps count seconds from January 1, 1900 in a 64-bit seconds-and-fraction layout used by network time protocol. The 32-bit low half of the seconds field wraps in 2036, which NTP handles with an era system rather than a Y2038-style crash.
A worked example that ties the family together
The same instant — August 7, 2026, 00:00:00 UTC — looks completely different in each format:
- Unix:
1786060800 - LDAP / FILETIME:
134305344000000000 - .NET ticks:
639216576000000000 - Mac HFS+:
3868905600
Notice the pattern: the formats are all just "elapsed time since a different reference point, in a different unit." Once you know the two ingredients — the epoch and the unit — any of them converts to any other with plain arithmetic.
Converting in practice
Each format has a dedicated converter on this site:
LDAP / Active Directory,
.NET ticks,
Chrome / WebKit time,
Excel / OADate,
Mac HFS+, and
NTP. All of them treat their
values as UTC by definition and use BigInt where 18-digit
counts would otherwise lose precision — two details that trip up hand-rolled
scripts more often than the epoch math itself.
First published · Last reviewed · Maintained and developed by the Real Epoch Converter team · [email protected] · Contact · Methodology
More guides
- What Is Unix Time? The Epoch Explained for Developers
- How to Read Unix Timestamps in Logs, Fast
- Seconds, Milliseconds, or Microseconds? Detecting a Timestamp’s Unit
- ISO 8601 vs Unix Time: When to Use Which
- Leap Seconds and GPS Time: Why Two Clocks Disagree
- Snowflake IDs: The Timestamps Hidden in Discord and Twitter IDs
- 7 Timestamp Bugs That Bite Every Developer
Every article is written by the Real Epoch Converter team and cross-checked against the specifications listed in its sources. To try what you just read, open the epoch time converter — the free online tool on the home page — or browse the FAQ.