Comment by porridgeraisin 2 days ago
Today you should use getFullYear() => 2025
getYear() returns 125 as it was standard for dates to be offset from 1900 (which led to the Y2K problem). This behaviour should be maintained forever. "Nothing is more important than backwards compatibility"
Or rather, that should be mindset, so that we can achieve at least 90% backwards compatibility in practice.
Java 1.0 (also released in '95) had the same behaviour. Java itself borrowed it from `struct tm` in libc, which has the same behaviour from back then up until today. It was standard back then. Whether we like it or not (I don't) doesn't change that fact. And like I said, nothing is more important than backwards compatibility.
It is just programmer education to know to add 1900 to years when using struct tm and also to use getFullYear() in JS.
Why is nothing more important than backwards compatibility between disparate languages written in different contexts for different contexts?
That javascript chose to offset from 1900 was simply because every system back then used to, including Java.
Once that had been done, future versions of javascript had to maintain the same behaviour. This is where I'm using the backwards compatibility argument.
Yes, a language that was created in 1995 was entirely justified in adopting a convention that would break within five years.