It’s not just a proposal, it’s already fully defined and almost completely implemented - I believe they’re just waiting on a standards update from ISO for time zone stuff.
Fun fact: infinities can be different sizes, such that one infinity can be larger than another.
They’re still infinities, with no end. Just of different absolute sizes. Fun stuff to rabbithole down into if you want to melt your brain on a lazy afternoon.
Even more fun: nobody can agree on how many there are (some people say none!), and mathematics is self-consistent regardless of if you assume certain ones definitely doordefinitely don't exist.
The definition of the Date object explicitly states that any attempt to set the internal timestamp to a value outside of the maximum range must result in it being set to "NaN". If there's an implementation out there that doesn't do that, then the issue is with that implementation, not the standard.
it may or may not be a monday - probably won't. it will be monday based on the (4000 | year) => !(leap year) rule, but by the year 275000 the difference will be so big that i am pretty sure people will make more rules to solve that.
This will be a tough one to fix. There must be millions upon millions of embedded systems out there with 16-bit epoch burned in.
They'll all be much tougher to find than "YEAR PIC(99)" in COBOL was.
Y2K wasn't a problem because thousands upon thousands of programmers worked on it well in advance (including myself) we had source code and plenty of static analysis tools, often homegrown.
The 2038 bugs are already out there...in the wild...their source code nothing but a distant dream.
48 replies
Well y275.8k will certainly be interesting
They’ll work on a solution in the year 275,759
…written in ES5, Python 2 and mostly Rust++
It's fun how oddly close that year is with 0°C in Kelvin: 273.15. Seeing 275.8K just instantly brought me back to chemistry...
Bold of you to assume no one will come up with a replacement date library rather than just getting rid of JS.
It’s javascript. We’ll have gone through 275,760 new datetime libraries before then, it’ll be fine.
String based date processing
Of course! There's already a proposal for a replacement Temporal object.
It’s not just a proposal, it’s already fully defined and almost completely implemented - I believe they’re just waiting on a standards update from ISO for time zone stuff.
slides £20 across the table make it end tomorrow
reserve me tickets for the inevitable shit show that follows 🍿
Also means you can't reference anything earlier than the late Pleistocene.
Nothing happens before c. 4000 AD anyway.
Sorry, that's also wrong. The entire universe, in its current state, popped into existence last Tuesday. It's been terribly inconvenient tho.
I wish we would have popped into a better existence.
We should never have coalesced from the quantum foam.
I thought it was last Thursday.
GODDAMMIT
Um excuse me time actually already ended in 1991
No, that was the world that ended in 2012.
Fun fact: infinities can be different sizes, such that one infinity can be larger than another.
They’re still infinities, with no end. Just of different absolute sizes. Fun stuff to rabbithole down into if you want to melt your brain on a lazy afternoon.
Even more fun: nobody can agree on how many there are (some people say none!), and mathematics is self-consistent regardless of if you assume certain ones definitely do or definitely don't exist.
In what unit? They're not scale invariant.
Also in case you're serious, I'm sure (by the pigeonhole principle) you'll run out of exponents just about as fast as you would run out of integers.
boy do i have a bad news for you... https://en.wikipedia.org/wiki/Floating-point_arithmetic#Accuracy_problems
there goes my plans to build a time machine in javascript
What people fail to see is that this is the largest date the API can store, not a magical cutoff date in the distant future.
You could create a date today and send it to the API, and it could potentially crash it, or create a buffer overrun.
The definition of the Date object explicitly states that any attempt to set the internal timestamp to a value outside of the maximum range must result in it being set to "NaN". If there's an implementation out there that doesn't do that, then the issue is with that implementation, not the standard.
No programming language should last 200,000 years
Replaced. Hotel? Trivago.
JavaScript shouldn't have lasted as long as it has and it's still used widely
Javascript 2 release date
please hide this. this is how john connor defeats skynet.
That's because this is the maximum integer that can be stored in a double precision floating point number without loss of precision, lol
I've got a bunch of freeze dried food from my backpacking days. Who wants to jump in on a business selling Y275.76K Survival Kits?
Yes, but will that be a Friday??
That will be a Saturday
it may or may not be a monday - probably won't. it will be monday based on the (4000 | year) => !(leap year) rule, but by the year 275000 the difference will be so big that i am pretty sure people will make more rules to solve that.
2036 to 2038 is gonna be wicked.
This will be a tough one to fix. There must be millions upon millions of embedded systems out there with 16-bit epoch burned in.
They'll all be much tougher to find than "YEAR PIC(99)" in COBOL was.
Y2K wasn't a problem because thousands upon thousands of programmers worked on it well in advance (including myself) we had source code and plenty of static analysis tools, often homegrown.
The 2038 bugs are already out there...in the wild...their source code nothing but a distant dream.
Well, I am comfortable leaving the upcoming disaster this will cause to the next generations.
I'll open a bug report
Be sure to cross-post it to the Usenet group for visibility.
Maybe by then my system will have recovered from this unresponsive javascript page
Too far away for my comfort.
We survived the 2000 crash, we will survive this
We definitely will not...
Speak for yourself, mere mortal!