Preferences

wiseowise parent
Cute. But things like these have tendency to be abused by “haha, js” crowd even if those things are irrelevant in practice.

rplnt
Generally true, but the Date and everything around it being absolutely incomprehensible and totally bonkers is very relevant in practice. It's pain to use and triggers billions of bugs daily. It's not an abuse to point out even more wtf about it.
samwho
This matches my experience. This is a bit of fun but I’m hoping it has the positive side effect of making people more cautious about how they use Date.
const_cast
I think it is relevant, it's a part of the standard library. It's one problem that JS has one of the smallest standard libraries, and it's another that the parts it does have just... don't work.

And, "don't use the standard library" is not a solution. Well I mean it is, but it's not free - there's caveats. Which tools do you choose? How do you make sure all your engineers use the same ones? How do you make sure nobody touches the standard library? It's not an easy problem.

AndroTux
date.getYear() => 125

If that’s not relevant, I don’t know what is.

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

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

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

This item has no comments currently.