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.
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.