FILETIME format counts 100-nanosecond intervals from January 1, 1601, at 00:00:00 UTC. But its headline overstates the case. Windows does not mean that every file physically stores its timestamps as one uninterrupted counter dating from 1601; rather, FILETIME is the common format Windows uses to represent many file times to applications, services, and network protocols.That distinction is more than pedantry for Windows administrators, developers, and forensic investigators. The 1601 epoch explains how Windows can compare timestamps across systems without relying on local clock settings, but it does not guarantee that a displayed “Date modified” value is precise, complete, or even derived from an NTFS timestamp. Microsoft’s documentation spells out several filesystem-specific exceptions that matter when files move between NTFS, FAT-formatted removable media, optical discs, and network shares.
Microsoft’s current Win32 documentation defines FILETIME as a 64-bit value containing 100-nanosecond intervals since the start of January 1, 1601 UTC. Raymond Chen, writing on Microsoft’s The Old New Thing, says Windows NT architect Dave Cutler confirmed the choice was driven by the Gregorian calendar’s 400-year cycle. The mathematics is sound; the blanket claim about “every file” needs the qualification.
FILETIME Is a Windows Time Format, Not a Universal Disk Format
A FILETIME value is best understood as an interchange format. Windows APIs such as GetFileTime, file-server protocols, and many Windows development frameworks use it to pass creation, access, write, and metadata-change times around as a single 64-bit quantity. A program does not need to parse locale-dependent text such as “9/16/2026 8:30 AM,” decide whether that means month-first or day-first notation, or guess which daylight-saving rule applied.
The two 32-bit fields in the traditional FILETIME structure combine into one 64-bit integer. At ten million ticks per second, a date in 2026 becomes a large number—roughly 134 quadrillion 100-nanosecond intervals after the 1601 starting point. Windows can convert that number into a human-readable local date for File Explorer or retain it as UTC for comparisons and logs.
The important caveat is that the API format is not identical to the on-disk representation of every filesystem Windows can read. NTFS stores timestamps in UTC, which makes the underlying value stable when a drive moves between time zones. FAT records times in local time and has far coarser fields. A FAT file’s creation time has 10-millisecond resolution, its write time has two-second resolution, and its access information is effectively a date rather than a time.
So a file copied to a USB stick formatted as FAT32 may still be returned to an application as a FILETIME, but the value Windows supplies has been converted from a less precise, locally interpreted source. The familiar 1601 epoch is part of the Windows-facing representation; it does not repair time information the source filesystem never preserved.
The 400-Year Calendar Calculation Was the Point
The Gregorian calendar looks irregular at short range. Years divisible by four are generally leap years, except years divisible by 100, except again years divisible by 400. That is why 1900 was not a leap year, 2000 was, and 2100 will not be.
Across 400 years, however, the rules settle into a complete repeating pattern: 303 ordinary years plus 97 leap years equal 146,097 days. That total divides exactly into 20,871 weeks. The weekdays and leap-year pattern align again at the end of the cycle, giving date-conversion code a clean boundary instead of an arbitrary historical starting point.
Chen’s account identifies 1601 as the first year of the then-current 400-year Gregorian cycle when Windows NT was designed, making the span from 1601 through 2000 a convenient full block. The choice was therefore not an inheritance from a pre-Windows operating system, an Elizabethan historical reference, or a compatibility compromise with MS-DOS. It was a deliberate decision to simplify calendar arithmetic in the new NT architecture.
There is a small documentation wrinkle worth noting. An older 2003 The Old New Thing post described Win32 FILETIME as beginning in 1600. Microsoft’s Win32 API documentation, Microsoft’s protocol specifications, and Chen’s later explanation consistently specify January 1, 1601. The 1600 reference is plainly inconsistent with the primary technical record and should be treated as an old typo, not a second Windows epoch.
Precision in the Format Is Not Precision in the Evidence
The 100-nanosecond unit often gets repeated as though every Windows timestamp can establish an event sequence to one ten-millionth of a second. It cannot. FILETIME has that representation granularity, but storage, caching, write behavior, hardware clocks, and filesystem policy determine the timestamp’s real resolution and reliability.
Microsoft explicitly warns that filesystems do not all record creation and last-access times the same way. NTFS itself can defer last-access updates by as much as an hour, and Windows disables ordinary NTFS last-access updates by default. A file opened at 10:05 may therefore retain a last-access timestamp from much earlier, even though the FILETIME field used to report it is capable of holding far finer increments.
Last-write times have their own qualification: Microsoft says the final write timestamp is not fully updated until all handles used for writing the file have closed. Administrators monitoring a log, database, virtual-disk image, or actively written archive should not assume a timestamp seen during the write represents the final persisted state.
This affects incident response as much as ordinary file management. A timestamp can support a timeline, but it should be compared with other evidence: the NTFS change journal where available, Event Viewer records, application logs, cloud-sync activity, EDR telemetry, and filesystem metadata. An attacker can also set file times deliberately, and a legitimate copy operation may assign a new creation time while retaining an older modified time. The date fields in Properties are useful facts, not self-authenticating proof.
UTC Avoids One Problem, Not Every Time-Zone Problem
The use of UTC means an NTFS timestamp identifies a consistent instant: a file written at 3:00 PM Pacific Standard Time and viewed in New York should refer to the same moment, displayed as 6:00 PM Eastern Standard Time. That is the behavior Microsoft documents for NTFS volumes.
FAT behaves differently because it stores times as local time. Microsoft gives the practical example: a file saved at 3:00 PM PST in Washington and then viewed in New York may still appear as 3:00 PM EST on a FAT volume. The stored value describes a wall-clock reading without the same durable UTC context, so moving media across time zones can produce an apparently shifted history.
Daylight saving time creates another trap. Microsoft documents that some FILETIME conversion paths use the computer’s current time-zone and daylight-saving settings, which may differ from the rules in effect when the file was created. Chen has also documented cases in which Explorer and Command Prompt displayed a file time differently by an hour because they followed different conversion behavior.
For routine desktop use, this normally amounts to a confusing hour in a file listing. For scripts that reconcile timestamps, backups that rely on time comparisons, or forensic work involving removable media, it is a reason to preserve the raw UTC value and record the filesystem type before drawing conclusions.
The 2038 Comparison Misses the Real Risk
The MakeUseOf comparison to the Year 2038 problem is directionally useful but incomplete. The traditional 2038 failure arises when Unix time is held in a signed 32-bit count of seconds from January 1, 1970. The positive range ends on January 19, 2038.
Windows FILETIME uses 64 bits and increments in 100-nanosecond units. Microsoft documents the related SYSTEMTIME structure as accepting years from 1601 through 30827. That places Windows well outside the practical horizon of the classic 2038 limit.
The safer lesson is not that a 64-bit Windows timestamp makes date handling trivial. It is that formats, range, signedness, resolution, conversion rules, and the storage layer all matter. A Windows service can use FILETIME correctly and still make a mistake by treating a local FAT timestamp as UTC, by assuming last access is current, or by doing unsafe arithmetic directly on the split high and low halves of the structure.
January 1, 1601 remains a durable Windows design choice because it gives the platform a mathematically tidy zero point and an enormous usable range. For anyone reading timestamps operationally, the date that matters most is still the one on the file—but the filesystem, time zone, and update behavior behind that date determine whether it tells the whole story.