Fixing JavaScript's Date (2017) | Hacker News Reader

Fixing JavaScript's Date (2017)

maggiepint.com

40 pointspcr91030333 comments

This one isn't mentioned:

  > d
  Thu Feb 27 2020 17:05:28 GMT-0600 (Central Standard Time)
  > d.getMonth()
  1

I'm as fond of zero-indexing as anyone, but this is ridiculous.

Agreed. This is probably my #1 annoyance.

Even worse, it's not even internally consistent: while the month of the year starts at 0, the day of the month starts at 1. This is one of the worst API design mistakes of Java, and Javascript blindly copied it. At least the newer Java APIs (the java.time ones) fixed that: the month starts at 1 with the newer APIs (when not using the enum). But I don't have much hope of Javascript copying the new and better API.

I definitely don't think Brendan "blindly" copied it. At the time, Sun was pushing Java hard. Netscape wanted in on that. So they delivered an edict to "make it look like Java". We can all say, "well I would have pushed back". But it's hard to say what would have happened. He'd have probably been taken off the project.

Hindsight really is 20/20.

>At the time, Sun was pushing Java hard. Netscape wanted in on that. [...] He'd have probably been taken off the project.

Can you elaborate on this? Was netscape owned/funded by Sun?

There was a partnership. The CNet article is still around. https://www.cnet.com/news/netscape-and-sun-unveil-javascript...

The reason there's an "exception" for days is that the numbers are the widely-used names for the day of the month. Months arguably don't have widely-used numeric names, although it's pretty reasonably to argue that because numeric month-and-day formatting is so ubiquitous it would have been okay to 1-index the months.

It occurs to me that "9/11" is the one date I can think of where the month is commonly verbally referred to by its number.

That's... a terrible argument.

1970-01-01T00:00:00 is the start of the Unix Epoch, it is definitely not 1970-00-01T00:00:00.

This is consistent across all the warty and various ways to represent the Gregorian calendar, the fifth month is always May, no exceptions.

I think parent means that we often say:

> I get my check on the first of the month

But never really say

> I'm going on vacation for the sixth (month) of the year

Seems like they are just trying to explain the bad decision, not justify it.

Yes, I'm not trying to justify it. And it's not just that we say "the fifth day of May," because it's also true that we can say "the third month." My point is that the fifth day of May is actually named "5" and there's no other name for dates (other than specially=named days, of course).

That consistent with days of the week, which start at 0 on Sunday.

The bigger WTF is getYear(), which returns the year minus 1,900.

Wasn't the reason for the 0-indexed month that this would make picking the name of the month from the 0-indexed array of month names easier?

> Months arguably don't have widely-used numeric names,

You forgot about east asian languages, which all use numeral months.

https://en.wikipedia.org/wiki/Chinese_calendar#Month

https://en.wikipedia.org/wiki/Japanese_calendar#Months

https://en.wikipedia.org/wiki/Korean_calendar#Months

It's bizarre that Java....Java....was able to fix this years before JS even really seriously considered it.

I don't know whether JS is fast-evolving or slow-evolving.

And also:

    > d.getDay()
    4   // that's the weekday, use getDate()
    > d.getYear()
    120 // that's the year minus 1900, use getFullYear()

That's at least as old as the C language, including also years being since 1900:

https://en.cppreference.com/w/c/chrono/tm

java.util.Date copied it from time.h and Javascript copied it from Java.util.Date.

ISO 8601 has a sensible date format which is an international standard. Gregorian calendar, YYYY-MM-DD, with MM from 01 to 12, and DD from 01 to 31. Days of the week are from 1 to 7, beginning with Monday.

java.util.Date has since been superseded by classes in java.time, which uses ISO 8601.

This is just one of the many things wrong with the Java Date API:

https://stackoverflow.com/a/1969651/130659

JS Dates are terrible, but not just the native stuff...there isn't a single good library either. [1]

A good library instants (1582852000000 ms since epoch), durations (5000 ms), periods (2 months), offsets (-0700), timezones (America/Denver), date (4/3/2019), and time (4:45 PM).

Instead I am stuck with good treatment of like two or three of these in any JS library I pick up -- usually instant and duration -- and I have to hammer things to fit.

[1] https://news.ycombinator.com/item?id=21669829

I've found js-joda is a good JS datetime library: https://github.com/js-joda/js-joda

Interesting, thanks!

I've used Joda and java.time a lot, and I have a very high opinion of both.

In case it wasn't immediately obvious, there's a Stage 2 tc39 proposal that was spawned from this blog post called Temporal:

https://github.com/tc39/proposal-temporal

At a glance, it does follow the same ideas as the great Joda Time library (now a part of the Java standard library), and there's currently a port of this library for JS which is quite nice:

https://github.com/js-joda/js-joda

Another oddity of JS's Date is that "Date()" returns a string whereas "new Date()" returns an object.

This makes it hard to do "class MyDate extends Date" when targeting ES5 from TS. In fact, if anyone knows an easy solution for that I'd love to hear it.

Your request is too broad, I suggest asking a question on StackOverflow explaining what the issue is exactly.

I didn't make a request. My post consists of two observations and an aside.

Thanks for your wonderful feedback though.

That is the wrong way to fish for that "easy solution" on HN. The proper way is to confidently state that there is no easy solution, which may inspire the HN hive mind to contradict you. That probably won't work ITT however since I spoiled it by pointing this out.

> In fact, if anyone knows an easy solution for that I'd love to hear it.

What’s this? You’re asking for a solution to “things that don’t work” ️

Dealing with dates is such a clusterfuck. Avoid it at all costs. Dates are a mix of political whims, astronomy theories, and historic artifacts, and works differently depending on what country you are in. With leap years and leap seconds, holidays, and summer/winter time adjustments.

The fix for any date/time issues in any language is replicate NodaTime (https://nodatime.org/)

NodaTime is great, as is the project it's based on JodaTime, which has since been deprecated in favor of the standard library java.time. https://www.joda.org/joda-time/

Hopefully other languages and platforms, including .NET, move to including a sane DateTime library in the standard library too.

Have you used https://js-joda.github.io/js-joda/ ?

> Now we can see that lots of issues with date are fixable. However, we are left with two things on our list that aren’t: mutability and parsing. The reasons that these things can’t be fixed relates to two concepts that TC39 has to deal with a lot – web compatibility and web reality.

Same with Java.

It was still able to introduce a new date API.

We all know it’s broken. More importantly, who’s job is it to fix it?

Reply on news.ycombinator.com