Date.toLocaleString doesn't respect options

[Yamboy1]

Date.toLocaleString always returns in the same format, no matter what options are given to it. I'm sure this isn't intentional, but it bugs me a bit, and i couldn't find another issue on the subject

[cknight]

In addition to options, the locale is not respected either. Example (my default locale should be "en-GB"):

const date = new Date(Date.UTC(2018, 5, 26, 7, 0, 0));   
const options = { weekday: 'long', year: 'numeric', month: 'long', day: 'numeric' };
console.log("raw:          ", date.toLocaleString());
console.log("locale en-US: ", date.toLocaleString("en-US"));
console.log("locale en-DE: ", date.toLocaleString("de-DE", options));
console.log("long output:  ", date.toLocaleString("en-US", options));

Deno output:

raw:           Tue Jun 26 2018 08:00:00 GMT+0100 (BST)
locale en-US:  Tue Jun 26 2018 08:00:00 GMT+0100 (BST)
locale en-US:  Tue Jun 26 2018 08:00:00 GMT+0100 (BST)
long output:   Tue Jun 26 2018 08:00:00 GMT+0100 (BST)

Curiously, node doesn't recognize locale either (and seems to default to en-US).

Node output:

raw:           6/26/2018, 08:00:00
locale en-US:  6/26/2018, 8:00:00 AM
locale en-DE:  Tuesday, June 26, 2018
long output:   Tuesday, June 26, 2018

Chrome output:

raw:           26/06/2018, 08:00:00
locale en-US:  6/26/2018, 8:00:00 AM
locale en-DE:  Dienstag, 26. Juni 2018
long output:   Tuesday, June 26, 2018

[cknight]

Interesting reading about this. Looks like v8 uses ICU to add internationalisation and deno would need additional work to support this.

[isAdrisal]

Duplicate of #1968?

[bnoordhuis]

Curiously, node doesn't recognize locale either (and seems to default to en-US).

Node only recently turned on support for all locales. With Node < v13.x, you need to install the full-icu package if you want more than just en-US.

That could be an option for deno if file size is a concern. I backtracked on that with node though, the smaller binary size doesn't make up for the inconvenience.

[ry]

We're going to have to include ICU eventually. But I'd like to punt on that until we have some of our other burning fires put out. Our binary size is severely bloated due to the TypeScript snapshot. If we could replace it with SWC, then I'd be much more comfortable adopting ICU...

[cknight]

@isAdrisal Likely a duplicate. My node installation has partial ICU support but not full ICU support, which likely explains the lack of locale support, but it does support (at least some of) the options as shown in the node output above.

[Yamboy1]

Maybe as a solution atm it would be nice to have some more date formatting tools in std/datetime, that's all i really need toLocaleDate for.

[cknight]

I'd be happy to work on that once my current PR is complete. I'd intended to expand the functionality in std/datetime next anyway so it's a good fit.

[kitsonk]

Our binary size is severely bloated due to the TypeScript snapshot. If we could replace it with SWC, then I'd be much more comfortable adopting ICU...

@ry even if we could move to SWC, we won't be able to carve down the size of the TypeScript binary until microsoft/TypeScript#35210 lands and we can cherry pick parts of the compiler we wouldn't have in Rust. Also like need microsoft/TypeScript#33502.

Maybe as a solution atm it would be nice to have some more date formatting tools in std/datetime, that's all i really need toLocaleDate for.

That seems way too counter intuitive to me... the capability is built into the language. We should find a way to at least include part of the ICU, and lazy load other locales. That pattern has been proven before.

This is effectively a duplicate of #1636 / #1968

[cknight]

Looking at this more deeply, I'm now of the belief that adding date formatting tools to Deno isn't the right way to go. Dates can be so complex with timezones, locales, etc. that at best we could only deliver a small subset of possibilities which javascript already offers by default (however, not currently supported by Deno). Best to wait for ICU support and get it right from the beginning I think, rather than build a half-baked solution to be deprecated later. As well, for most people's needs who have a specific date formatting requirement, it should be easy to build their own specific use case date formatting routine.

@kitsonk Not sure how much control we have over the typescript compiler (I'm guessing not much?), but it'd be cool if the typescript compiler could warn on the use of Date.toLocaleString and such other methods that Deno doesn't support ICU yet, etc. which would be a better user experience than puzzling why the run time behaviour isn't working as expected. Probably too hard/not worth it, but the UX here isn't great, though I suppose Node lived with it for years.

[kishiguro]

With updates of #1968, we may have full ICU support in Deno.

const date = new Date(Date.UTC(2018, 5, 26, 7, 0, 0));   
const options = { weekday: 'long', year: 'numeric', month: 'long', day: 'numeric' };
console.log("raw:          ", date.toLocaleString());
console.log("locale en-US: ", date.toLocaleString("en-US"));
console.log("locale en-DE: ", date.toLocaleString("de-DE", options));
console.log("long output:  ", date.toLocaleString("en-US", options));

Now Deno with ICU's output is something like this.

raw:           6/26/2018, 4:00:00 PM
locale en-US:  6/26/2018, 4:00:00 PM
locale en-DE:  Dienstag, 26. Juni 2018
long output:   Tuesday, June 26, 2018

[ry]

duplicate of #1968