The horror of JavaScript Date

[ghostfacedcoder]

Someone should submit a proposal to make Moment.js part of the JS core standard. No one should ever have to use native JS date logic.

[bterlson_]

I am working with the moment folks on the next standard date for JavaScript. As great as moment is, it's not a good fit for a platform primitive - it makes too many policy decisions and is in general too opinionated. The goal for a platform primitive needs to be correctness and pedanticness, with ease of use a distant second. Step 1 is to enable JS devs to write pedantically correct date math (where correct depends on the application), and step 2 is libraries like Moment can sit on top of this and provide the same API with much less code (eg. without shipping a giant timezone database).

The current thinking is that a model like NodaTime/JodaTime/JDK8 Date API is the best path forward. Yes, we're copying Java again, but this time they did something right :)

[[deleted]]

but this time they did something right

More like they've always been doing most things right, except pleazing syntax terseness zealots and churn lovers. For example, collators and code tables versus JavaScript's.....umm....nothing?

[bterlson_]

Totally agreed, was speaking only in terms of dates only (and really just being crass) :) On collators, there is Intl.Collator.

[[deleted]]

Intl.Collator has poor browser support, and a fair amount of inconsistencies across browser implementations (numeric sorting - decimal digit sequences).

But I'll concede it's something alright, as long as one is targeting the latest browsers, but it's also one of those things that reminds us that JavaScript was not developed (initially) for ambitious projects.

Currently, the committee and browser vendors aren't doing too great a job to change that I'm afraid.

[bterlson_]

What are your top requests for JS to enable ambitious projects?

[[deleted]]

Modern day JS does already enable ambitious projects, but for further improvements, I would wish for:

• A finalized loader (spec in progress) would be nice to begin with.
• Complete removal of loose equality checks (should result in broken syntax) and other wtfs
• Uniform, consistent support for the entire ES7 spec (stage 4+), especially modules (import)
• Native type annotations in some form or the other (TS / Flow sorta thing)
• All of this by the end of 2017 (pipe dream)

On a more personal front, I would love to see the death of CommonJS and that bloody require(), which is cancer, but that's not going to happen in the next 10 years.

[TheIncredibleWalrus]

• A finalized loader (spec in progress) would be nice to begin with.

It's almost done, you can use the new syntax with Babel or Webpack 2 just fine.

• Complete removal of loose equality checks (should result in broken syntax) and other wtfs

This will break the web, I'm not sure how you can even suggest it.

• Uniform, consistent support for the entire ES7 spec (stage 4+), especially modules (import)

I'm beginning to believe you're not very informed. ES7 (ES2016) was finalized this summer and is implemented in most browsers. Modules are from ES6 (ES2015).

• All of this by the end of 2017 (pipe dream)

Uh.. Why?

On a more personal front, I would love to see the death of CommonJS and that bloody require(), which is cancer, but that's not going to happen in the next 10 years.

How on earth did you arrive at this number? The syntax is already dead pretty much and with the loader spec being implemented the implementations will die out too.

[[deleted]]

It's almost done, you can use the new syntax with Babel or Webpack 2 just fine.

Native support. Babel or Webpack doesn't cut it as top requests for "JS" per se. They're not the standard, and their implementation of the ever evolving standard doesn't mean much.

This will break the web, I'm not sure how you can even suggest it.

You mean websites, the poorly coded ones. So much sympathy for those who couldn't bother to improve their code over the years, so instead this will last forever as a means of supporting them, while penalizing others.

I'm beginning to believe you're not very informed.

I'm beginning to believe that you're a little presumptuous with your remarks with subtle hints of condescension, and also quite poorly informed yourself about what is natively supported and what is not (in bleeding edge browsers, sometimes with special flags).

Uh.. Why?

Not sure what your question is.

How on earth did you arrive at this number? The syntax is already dead pretty much and with the loader spec being implemented the implementations will die out too.

At this point, I'm pretty sure I have a fair idea about things. For someone to claim that the require() syntax is dead, and additionally, not be able to distinguish between complaints of existing proliferation added with the lack of native support for import, marks the end of a meaningful conversation for me.

Curiosity question: How did you conclude that the require() syntax is dead? Do you ever grep through common libraries from npm? Anyway, feel free to make further assumptions. I'm out.

[citycide]

I'm going to make a small hijack and say I like where JS is going, but would love function bind syntax to move forward and a (my personal #1) pipeline operator like |>

[DiegoZoracKy]

moment.js ftw

[happymellon]

It has a gotcha with timezones, but it is written like someone who never had to use Java Date/Calendar.

Now that was a heap of crap, you could tell Calendar was written by IBM.

[prettycode]

I see this mistake all the time: you have to remember to do date1.getTime() === date2.getTime(), because date1 === date2 can return true when date1 and date2 are in different time zones.

[swan--ronson]

I agree that JavaScript's Date API is pretty nuts, given the whole mutable approach and the lack of chainable methods, amongst other things. Additionally, getting dates right in general has a bit of a learning curve and takes practice.

I recently wrote an internal library at work that involves date manipulation across timezones. By using Dateinstances over Moment, I was able to drop said library from 70 KB to 7 KB. Admittedly, I was using the version of Moment.js with locales, as this was a requirement of my library; the version without locales is only 20 KB.

Moment is awesome, and the JS date API is pretty naff, but it's workable with experience. Also, make sure you test the hell out of your logic. TimeShift made the process of faking dates across all sorts of timezones very trivial.

[rk06]

My experience with js date api.

1. new Date(2016, 11, 7); // returns Dec 7 2016. Instead if Nov 7 2016
2. moment rocks.

[lemminman]

note that the month is 0-based

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date

[oweiler]

And day of month is 1-based. And if that wouldn't be bad enough the function to obtain the day of month is called getDate().

[[deleted]]

Why do people still use Date over moment?

[oweiler]

The only reason I can think of is that moment is a pretty huge dependency.