Windows Will No Longer Be Supported After 12/31/2107 At 3:59:58 PM?

Edwin · 10 Jan 2018

pepanee said:

So the Android operating system will probably take over... and the Space Androids will claim that company's ownership. HAH. The future is gonna be a strange place.

And I'll still be hunched over my keyboard, at about 140 years old, with rigor mortis settin in, waitin for Build 17063 to install!!!

kronckew · 10 Jan 2018

The Borg will be landing then. Don't ask me how i know, I'd have to assimilate you early. Resistance is futile.

Windows Will No Longer Be Supported After 12/31/2107 At 3:59:58 PM?-borg.jpg

PolarNettles · 10 Jan 2018

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.

NTFS uses 64 bits for the timestamp, so it will overflow somewhere in September of 30828.

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.

KCR · 10 Jan 2018

Edwin said:

And I'll still be hunched over my keyboard, at about 140 years old, with rigor mortis settin in, waitin for Build 17063 to install!!!

Lol, it could be worse...

Windows Will No Longer Be Supported After 12/31/2107 At 3:59:58 PM?-kcr-still-reading-2.jpg

KCR

Bree · 10 Jan 2018

PolarNettles said:

NTFS uses 64 bits for the timestamp, so it will overflow somewhere in September of 30828.

No, it's earlier than that because it starts counting in 100ns intervals from January 1, 1601 (UTC). See my post #10.

PolarNettles · 10 Jan 2018

Bree said:

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.

Bree · 10 Jan 2018

PolarNettles said:

I was going by the analysis in Interpretation of NTFS Timestamps | Forensic Focus - Articles ....

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.

pepanee · 10 Jan 2018

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

revmike · 10 Jan 2018

You people have way too much free time on your hands:)