It really, genuinely blows my mind that someone invented a new way to Y2K bug *after Y2K*.
Even if it was invented on Jan 1 2000, INTS WEREN'T THAT PRECIOUS OF A RESOURCE THEN, YOU CAN AFFORD TO SPEND 3 ON STORING A DATE AS YEAR/MONTH/DAY
I don't know who else needs to know this, but an INT variable has limits..
Type int, which uses 32 bits giving it a range of -2147483648 to +2147483647, inclusive..
Today's date string ["YYMMDDHHMM"] is 2201010001, which is larger than that.
HAPPY NEW YEAR!
1
3
25
oh wait sorry it's five components, YOU CAN STORE FIVE INTS
The conspicuous lack of seconds in the format shows they at least realized you can't pack *twelve* decimal digits into a 32-bit signed int. Pity they didn't ask how much of ten digits actually fits.
1
4
Just... just don't invent weird custom date formats. Use an s64 unix timestamp. It'll work for approximately forever and everyone understands it.
JS uses an f64 of milliseconds, which is... sufficient. It'll work out past Y200K, at least. (And just lose accuracy after that.)
1
1
2
Even DOMHighResTimestamp, which uses an f64 of *microseconds*, will still work out to 2250 or so.
A timestamp format that only works within a *21-year period* is just sad.
2
4
DOMHighResTimeStamp isn't used to hold clock time, though. It's for interval time. developer.mozilla.org/en-US/…
2
Er, except MDN says it's a value in milliseconds, accurate to around 5 microseconds, so that's the wrong threshold. Oops.
Jan 1, 2022 · 8:14 PM UTC
1