New
#11
NTFS uses 64 bits for the timestamp, so it will overflow somewhere in September of 30828.PolarNettles: Wow cool! I tried searching for that date but didn't find that result. Thanks for that link. I remember hearing about that 2037 bug or whatever back then, but noticed that this bug was fixed. On the site, they say FAT Filesystems, they gotta update to NTFS also.. or I just missed seeing that. And yes: "4PM Pacific time is 0:00 UTC".
BUT wait! What about that last second of 2107!!! The last second doesn't exist! I guess Microsoft added that as a little Easter Egg or whatever. HAH they got me good on that one.
Based on Design of the FAT file system - Wikipedia it looks like the modified time only has a 2-second granularity, so it would stop at 11:59:58. The creation time has 10ms resolution so you should be able to get to 11:59:59 if you try to modify that.
No, it's earlier than that because it starts counting in 100ns intervals from January 1, 1601 (UTC). See my post #10.
I was going by the analysis in Interpretation of NTFS Timestamps | Forensic Focus - Articles which shows the maximum FILETIME to be 0x7FFF FFFF FFFF FFFF.
This corresponds to:
2^63 ticks * 100ns/tick * 1s/1E9ns * 1hr/3600s * 1day/24hr * 1yr/365.25days = ~29227 years
1601 + 29217 = 30828
Edit: Adjusting calculation to take into account leap years.
I see, so why the 2107 cut-off then? It's a puzzle...
Edit: Oh, I see they covered that too.
Windows Explorer GUI:
Timestamp range:
1980-01-01 00:00:00 — 2107-12-31 23:59:57
2107-12-31 23:59:58 and :59 are shown as ” (blank)
Remaining timestamps outside the range are translated as ” (blank) .
It must be noted that the timestamp range only refers to the times shown in the GUI list. When the timestamp of an individual file is examined in the file property dialog (see below), the coverage appears to be full range of years.
All this info is so complicated.. all I understood was what KCR said: I'm gonna be a skeleton trying to study my math homework from that book
LOL