4 ms·

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 anoth

by ljm 5y ago

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.

zeroonetwothree 5y ago
It made more sense before 2000 of course. And they can’t really change it without breaking many things.
cookie_monsta 5y ago
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.
iso1631 5y ago
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)
eCa 5y ago
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.
- jameshart 5y ago
  "Back then" for Javascript was 1995. The phrase "millennium bug" was already well established in the public mind by then.
jasamer 5y ago
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.
- jazzyjackson 5y ago
  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
  - cookie_monsta 5y ago
    > 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?
    - 6510 5y ago
      https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/getDate https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... lol
    - jazzyjackson 5y ago
      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.
cbsks 5y ago
date.getYear() 99: 1999 100: 2000 … 122: 2022
jcranmer 5y ago
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."

by ljm 5y ago

zeroonetwothree 5y ago

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

cookie_monsta 5y ago

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.

iso1631 5y ago

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)

eCa 5y ago

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.

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

jasamer 5y ago

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.

jazzyjackson 5y ago
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
- cookie_monsta 5y ago
  > 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?
  - 6510 5y ago
    https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/getDate https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... lol
  - jazzyjackson 5y ago
    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.

cbsks 5y ago

date.getYear() 99: 1999 100: 2000 … 122: 2022

jcranmer 5y ago

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