Real Epoch Converter logo realepochconverter
guide

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 — from GetFileTime(), the registry, and NTFS metadata.
  • Active Directory / LDAP attributes — values such as pwdLastSet, accountExpires, lastLogon, and whenChanged are FILETIME counts, exposed through the ADsLargeInteger type. PowerShell's Get-ADUser prints 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 2082844800 seconds 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.

Copied