Skip to tool
ecech.
🕑 Date, Time & Timezone

FILETIME Counts Ten-Millionths of a Second Since 1601

The 18-digit number in a registry export or an Active Directory dump. Too large for a JavaScript number, so parsing it the obvious way loses digits.

UTC

Unix seconds

FILETIME

Sub-second remainder

ticks below one second

Every representation

Values worth recognising

Advertisement

How the calculation works

Two epochs, 369 years apart 1601 FILETIME zero 1970 Unix zero 2100 116,444,736,000,000,000 ticks 11,644,473,600 seconds — the whole conversion

How to Use This Tool

Paste a FILETIME in decimal or hex and get a date, or go the other way. Everything is done with exact integer arithmetic.

What the number means

A FILETIME is a count of 100-nanosecond intervals — usually called ticks — since 1 January 1601 UTC. There are 10,000,000 ticks in a second and 864,000,000,000 in a day, which is why the values are so long.

Converting to Unix time is a single subtraction and a division:

unix_seconds = (filetime − 116444736000000000) ÷ 10000000

That constant is the 11,644,473,600 seconds between the two epochs, expressed in ticks. It is worth recognising on sight: a FILETIME equal to it is exactly the Unix epoch.

Why 1601

The Gregorian calendar repeats on a 400-year cycle, and 1601 begins the cycle that was current when the format was specified. Choosing the start of a cycle makes leap-year arithmetic uniform across the whole representable range, which matters when the range is thousands of years long.

It is not an arbitrary date, and it is also not a date anything was recorded on — a FILETIME near zero is almost always uninitialised memory rather than a seventeenth-century event.

Where exact integers run out 2⁵³ safe integer 9,007,199,254,740,991 a 2020s FILETIME 133,000,000,000,000,000 — about 14 times larger parseInt gives a number that looks right and is wrong in the last digits. BigInt is the only correct way to read one.
The rounding is silent, and the resulting date is usually only seconds out — which is worse.

Precision is the trap

A JavaScript number holds integers exactly only up to 253, which is 9,007,199,254,740,991. A current FILETIME is around 1.33 × 1017 — about fourteen times larger — so reading one with parseInt or Number() rounds it.

The failure is nasty because it is small. The date comes out looking entirely plausible and is wrong by some fraction of a second, or occasionally by more. Anything comparing two timestamps for equality, or sorting by them, will then behave strangely for reasons that do not show up in the output.

This page uses BigInt throughout, so the digits you paste are the digits used.

Where you meet these

  • Active Directory stores lastLogonTimestamp, pwdLastSet and accountExpires as FILETIME. These are the values most people are converting.
  • Registry exports and many Windows event log fields.
  • NTFS file creation, modification and access times.
  • Forensic tools, which frequently present raw ticks rather than a formatted date.

The sentinel values

Two values mean "not set" rather than a date, and converting them produces nonsense:

  • 0 — never set. It converts to 1601-01-01, which is not a claim about anything.
  • 9223372036854775807 (263−1) — the "never expires" marker on accountExpires. It converts to a date around the year 30828 and means the account has no expiry.

A report that shows users whose accounts expired in 1601 has converted the first without checking. This page flags both.

The high and low pair

The underlying structure splits the value into two 32-bit halves, and some tools print them separately as dwHighDateTime and dwLowDateTime. Recombining is high × 232 + low, which the pair option above accepts directly — and which is another place the arithmetic overflows an ordinary number.

Advertisement

Frequently Asked Questions

What is a Windows FILETIME?
A count of 100-nanosecond intervals since 1 January 1601 UTC. There are 10,000,000 ticks per second, which is why the values run to eighteen digits.
How do you convert FILETIME to Unix time?
Subtract 116444736000000000 and divide by 10000000. That constant is the 11,644,473,600 seconds between the 1601 and 1970 epochs expressed in ticks — a FILETIME equal to it is exactly the Unix epoch.
Why does 1601 matter?
The Gregorian calendar repeats on a 400-year cycle and 1601 starts the cycle current when the format was defined, so leap-year arithmetic is uniform across the whole representable range.
Why is my FILETIME conversion slightly wrong?
Almost certainly precision. JavaScript numbers hold integers exactly only up to 2^53, about 9.0×10^15, and a modern FILETIME is around 1.33×10^17. parseInt rounds it silently and the resulting date looks plausible while being fractionally wrong.
What does a FILETIME of 0 mean?
Not set. It converts to 1601-01-01, which is not a claim that anything happened then. Similarly 9223372036854775807 is the 'never expires' sentinel on accountExpires, not a date around the year 30828.
What are dwHighDateTime and dwLowDateTime?
The two 32-bit halves of the value. Recombine them as high × 2^32 + low — another place where ordinary number arithmetic overflows, so use exact integers.

Related tools in Date, Time & Timezone

Browse all Date, Time & Timezone tools
A handwritten note reading ecech.com resting on the keyboard used to build the site.

Made by one person

ecech. is not a content farm. Every tool here is written and checked by hand, one at a time, by someone who wanted the tool to exist and could not find a version that showed its working.

No accounts and no sign-in, and nothing you type reaches a server — every calculation on this page runs inside your browser. The ads are served by Google and do set their own cookies, which is set out in full on the privacy page. More about the site.