Why Windows measures time differently

A Windows FILETIME is a 64-bit count of 100-nanosecond intervals since January 1, 1601 UTC — not the Unix epoch (January 1, 1970) that most other systems use, and not measured in seconds or milliseconds. The 1601 epoch is a historical artifact of when the format was designed relative to the Gregorian calendar's 400-year cycle; the 100ns resolution is finer-grained than Unix time's traditional 1-second resolution, which is part of why Windows can represent sub-millisecond timestamp precision in places Unix timestamps traditionally couldn't.

Where these values actually turn up

FILETIME isn't just a display format in Windows — it's the native on-disk representation for NTFS timestamps (creation, modification, access, MFT change), registry key LastWriteTime, and many EVTX event log fields, all stored as raw 64-bit integers. Forensic and log-analysis tooling frequently surfaces these as the raw number rather than converting them, especially when working from a low-level dump or a tool that doesn't bother with the conversion — which is when a quick converter like this one is the fastest way to turn "132223104000000000" into an actual date without writing a script for a one-off lookup.

The math itself needs BigInt rather than a regular JavaScript number, since a 64-bit FILETIME value exceeds the ~53 bits of integer precision a JS double can represent exactly — using a plain Number here would silently produce a slightly wrong timestamp on values this large.