Hacker News Reader

Comment by ljm | Hacker News Reader

I forgot how bad JS's date API was until I tried getting the year out of a date.

    var date = new Date()
    date.getYear() // 122

I plugged this into another object and couldn't understand why it was setting the date to 0122. Like, what significance does 122 years from 1900 even have?

Turns out I had to use getFullYear, which is of course perfectly intuitive.

View on HN

I used the JS Date API for the first time a few months ago, and wrote something like

    date.getYear() + "-" + date.getMonth() + "-" + date.getDay()

in the hope of getting something like "2022-1-4".

The actual result for that date is "122-0-2" - not a single component of the date was what I expected.

date.toLocaleDateString ("fr-CA") would have got you there, but yea agreed 0 indexed months are whack.

I'm sure you've read the docs since then but just for the viewers at home:

s/getYear/getFullYear

s/getDay/getDate

getYear is oldfashioned, years since 1900. getDay is day-of-the-week, 0 for Sunday, 1 for Monday, etc

> 0 indexed months are whack

Why, if everything else in JS is 0 indexed? Isn't consistency a good thing in a language? If they'd gone the other way, wouldn't there be people here complaining that 1 indexing is whack?

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

lol

Well because days are returned 1-indexed and calendars in general are 1-indexed, but of course the internal 'getMonth' method isn't meant to be a calendar, it's meant to provide an array index to ["January", "February", ...] as an interface to the other methods of printing a human-readable form.

Well yes, as it's an extention of code written in the 1970s, when dates were most commonly referred to with 2 digits.

Even when javascript was written (and likewise with things like perl and php - and of course the underlying function dated back to the 70s ), it was still quite common for people to write dates by hand as 6/6/96 for June 6th 1996, hence people would often write something like

print day() + "/" + mon() + "/" + year()

If you wanted to put a 4 digit year many people

print day() + "/" + mon() + "/19" + year()

After 2000 came round, many sites would claim the year was 19100, I still saw these sites until well into the late 00s

However some people wrote print day() + "/" + mon() + "/" + (1900 + year())

Which would give the correct display.

Changing year() from returning a 2 digit (which in the 80s and even in the 90s was often preferable) to 4 digits would be a breaking change. Changing it to being "the last two digits" rather than "number of years since 1900" would be a breaking change. That's not something that people like to do, hence things like "getFullYear" to return a 4 digit year (or 3 digit for <1000 etc)

To be fair getYear has been deprecated for over 20 years (a bit after it was deprecated in Java for the same reason). The Y2K problem was a real thing in lots of places.

The JS Date API was cribbed wholesale from Java's java.util.Date, which was cribbed wholesale from POSIX (and thus Unix) date APIs, which was designed in the 1970s. But both of the cribbings preferred compatibility with the older API rather than fixing obvious warts in the API like "year is since 1900, not 1 BC" or "month is 0-based instead of 1-based."

It made more sense before 2000 of course. And they can’t really change it without breaking many things.

Back then it was quite common to only care about two-digit years, and by implication only years from the 20th century.

This kind of feature[1] lead to many potential Y2K bugs.

[1] Which it shares with Perl and probably many other languages.

"Back then" for Javascript was 1995. The phrase "millennium bug" was already well established in the public mind by then.

date.getYear()

Reply on news.ycombinator.com