4 ms·

date.getYear() => 125 If that’s not relevant, I don’t know what is.

wiseowise 1y ago
> date.getFullYear() => 2025 `getYear` is literally deprecated everywhere and is not part of the spec. https://tc39.es/ecma262/multipage/numbers-and-dates.html#sec-date.prototype.getfullyear https://tc39.es/ecma262/multipage/numbers-and-dates.html#sec...
- jameshart 1y ago
  Right, but it exists and looks correct and runs and won’t trigger any kind of error if you write code that uses it. This is what we call a ‘foot gun’.
  - hombre_fatal 1y ago
    On the other hand, you notice it the second you go use the software you just wrote to ensure it works. So it’s more like a foot dollar store water gun.
    - const_cast 1y ago
      No, it's a proper footgun, same as dereferencing a nullptr in C++. You'll notice that too - doesn't mean it's not a footgun. And, in fact, most C++ compilers today will actually warn you when you derefernence a nullptr in a stupid, obvious way. Evidently, JS has not caught up to this incredibly sophisticated technology /s.
      - jameshart 1y ago
        JS has caught up - it has a sophisticated compilation and linting ecosystem called ‘TypeScript’. Which at least will tell you you’re using a deprecated API, but won’t overcome the dumb API naming choices JavaScript blindly imported from Java
        const_cast 1y ago
        We've come full circle. The build systems for JS, a scripting language, make C++ compilation look trivial. And, unfortunately, that's reflected in the compile times.
porridgeraisin 1y 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.
- jameshart 1y ago
  Yes, a language that was created in 1995 was entirely justified in adopting a convention that would break within five years.
  - porridgeraisin 1y ago
    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.
    - wewtyflakes 1y ago
      Why is nothing more important than backwards compatibility between disparate languages written in different contexts for different contexts?
      - porridgeraisin 1y ago
        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.
        1y ago

> date.getFullYear() => 2025 `getYear` is literally deprecated everywhere and is not part of the spec. https://tc39.es/ecma262/multipage/numbers-and-dates.html#sec-date.prototype.getfullyear https://tc39.es/ecma262/multipage/numbers-and-dates.html#sec...

jameshart 1y ago
Right, but it exists and looks correct and runs and won’t trigger any kind of error if you write code that uses it. This is what we call a ‘foot gun’.
- hombre_fatal 1y ago
  On the other hand, you notice it the second you go use the software you just wrote to ensure it works. So it’s more like a foot dollar store water gun.
  - const_cast 1y ago
    No, it's a proper footgun, same as dereferencing a nullptr in C++. You'll notice that too - doesn't mean it's not a footgun. And, in fact, most C++ compilers today will actually warn you when you derefernence a nullptr in a stupid, obvious way. Evidently, JS has not caught up to this incredibly sophisticated technology /s.
    - jameshart 1y ago
      JS has caught up - it has a sophisticated compilation and linting ecosystem called ‘TypeScript’. Which at least will tell you you’re using a deprecated API, but won’t overcome the dumb API naming choices JavaScript blindly imported from Java
      - const_cast 1y ago
        We've come full circle. The build systems for JS, a scripting language, make C++ compilation look trivial. And, unfortunately, that's reflected in the compile times.

porridgeraisin 1y 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.

jameshart 1y ago
Yes, a language that was created in 1995 was entirely justified in adopting a convention that would break within five years.
- porridgeraisin 1y ago
  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.
  - wewtyflakes 1y ago
    Why is nothing more important than backwards compatibility between disparate languages written in different contexts for different contexts?
    - porridgeraisin 1y ago
      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.
      - 1y ago