Convert a Windows FILETIME deletion timestamp to a readable date
2 min read
At offset 0x10, every $I file holds the deletion time as a 64-bit
little-endian Windows FILETIME: the count of 100-nanosecond intervals
since 1601-01-01 00:00:00 UTC. The 1601 epoch is what trips people up.
Same format that powers $STANDARD_INFORMATION in the
MFT, most timestamps in the
registry, and several columns in
SRUM and EVTX.
Converting it
Given the 64-bit value T:
- Seconds since 1601:
T / 10_000_000 - Shift to the Unix epoch: subtract
11_644_473_600(the seconds between 1601-01-01 and 1970-01-01) - The result is a Unix timestamp in UTC — feed it to any date library.
unix_seconds = (filetime / 10_000_000) - 11_644_473_600
For sub-second precision, keep the remainder of step 1 as fractional seconds.
Quick reference
| Concept | Value |
|---|---|
| Epoch | 1601-01-01 00:00:00 UTC |
| Unit | 100-nanosecond intervals (1e-7 s) |
| 1601→1970 offset | 11,644,473,600 seconds |
| Byte order | Little-endian, 8 bytes |
| Range | Year 1601 to roughly year 30,828 |
Common conversion mistakes
- Treating the value as Unix seconds. A real FILETIME is on the
order of
1.3 * 10^17. Render that as Unix and you land in the year 4,000,000,000. - Endian flip. Always little-endian on disk. Some hex viewers show big-endian by default; double-check by computing the value yourself.
- Reading the wrong eight bytes. Offset is
0x10, not0x08(which is the original file size). Easy to swap when squinting at hex. - Local-time render with no label. Two analysts in different timezones will produce two reports that disagree. Render UTC by default and label any local conversion.
Why timezone discipline matters
The FILETIME carries no timezone. It is always UTC. Two real cases where the discipline mattered:
- An exfil case where the suspect's laptop logged a delete at
09:31 UTC. The analyst rendered local time, but the laptop was on a flight in a different timezone. Without the explicit UTC label, the timeline did not align with the corporate VPN logs. - A ransomware case where rolling deletion timestamps lined up with shift handoffs in EMEA — but only if you rendered in UTC. Local-time rendering smeared the burst across two business days and obscured the pattern.
Always export to ISO-8601 UTC. Always render UTC by default. Label any local-time view.
Further reading
Frequently asked questions
- What is a Windows FILETIME?
- A 64-bit little-endian integer counting the number of 100-nanosecond intervals since 1601-01-01 00:00:00 UTC. The Recycle Bin $I file stores the deletion time in this format at offset 0x10.
- How do I convert FILETIME to a normal date?
- Divide the value by 10,000,000 to get seconds, subtract 11,644,473,600 (seconds between 1601 and 1970), and treat the result as a Unix timestamp in UTC.
- Why is the timestamp in UTC?
- Windows records the FILETIME in UTC, with no timezone stored. Always present it as UTC (or label the timezone explicitly) so a deletion event is unambiguous on a timeline.
- Does this tool convert the timestamp for me?
- Yes. The parser reads the FILETIME from the $I file and shows it in your locale, while CSV export keeps a strict ISO-8601 UTC value so timelines stay consistent across timezones.