Chakracore: Incorrect time reported by Date#toLocaleString

[bterlson]

new Date("1986-06-13T15:31:28-04:00").toLocaleString("en", {hour: "numeric", hour12: false});

Actual: 12:00
Expected: Truth about what time it is (12:31?)

Other browsers give me 12 for this case.

[bterlson]

/cc @leaverou who instead sees 15 for other browsers and I'm not sure what's going on.

[LeaVerou]

I suspect the 12 vs 15 is due to a difference in our timezones, and it doesn't really matter anyway.
The issues here are that:
a) Minutes are reported, which is incompatible with every other browser
b) The reported minutes are wrong.

[dilijev]

FWIW, here's a couple of short tests to show what's probably going on here:

> es -is -h d8,node,sm,ch-master -e "new Date('1986-06-13T15:31:28-04:00').toLocaleString('en', {hour: 'numeric', hour12: false, timezone:'UTC'})"
## Source
print(new Date('1986-06-13T15:31:28-04:00').toLocaleString('en', {hour: 'numeric', hour12: false, timezone:'UTC'}))

#### d8, sm, node
12

#### ch-master
?12?:?00


> es -is -h d8,node,sm,ch-master -e "new Date('1986-06-13T15:31:28-04:00').toLocaleString('en', {hour: 'numeric', minute: 'numeric', hour12: false})"
## Source
print(new Date('1986-06-13T15:31:28-04:00').toLocaleString('en', {hour: 'numeric', minute: 'numeric', hour12: false}))

#### d8, sm, node
12:31

#### ch-master
?12?:?31

As for the reason there are only two answers and only Chakra is different, IIRC all the other browsers are using the ICU library for globalization, @bterlson can probably confirm -- and Chakra is using Windows Globalization to be consistent with the rest of Windows.

The spec allows these strings to be implementation-defined. Therefore, we provide the information requested in an implementation-defined template. In this case, the information requested is hours-only, and Windows Globalization has displayed that information in a format which resembles the usual hh:mm time format (with BiDi markers for embedding an English time easily in RTL languages like Arabic). In this case, there is no information selected for minutes, so the minutes are set to the default value 0. This can be used to display hour-only time in a familiar format. Obviously, based on the implementation used by other browsers, you might expect to see simply a plain hours format. If the intent is to get a plain number for the hours, JavaScript provides this as new Date().getHours().

> es -is -h d8,node,sm,ch-master -e "new Date('1986-06-13T15:31:28-04:00').getHours()"
## Source
print(new Date('1986-06-13T15:31:28-04:00').getHours())

#### d8, sm, ch-master, node
12

I'll investigate deeper. If the string is coming from within the Windows Globalization library, there's not much we can do here (under WinGlob anyway, see https://github.com/Microsoft/ChakraCore/issues/2919 for our work item to implement Intl with ICU). If this choice of template was made somehow in Chakra code, we might be able to make the WinGlob implementation provide an answer more like ICU implementations.

[bterlson]

Confirm: the primary reason V8, SM, and JSC agree here is because they all use the same underlying library (ICU).

[LeaVerou]

If the intent is to get a plain number for the hours, JavaScript provides this as new Date().getHours().

I’m aware. That does not allow customizing the timezone, so not an alternative for every case. The issue here is not how to get the numeric hour (even if I didn't know how to do that, it would be a question for a stack overflow, not this bug tracker), it's the incompatibility between Chakra and other engines.

[maggiepint]

If I read this correctly, the question is whether Chakra should give only the hour date part back when invoked this way.

I would tend to agree that the 402 spec doesn't require this behavior - at least as I understand it. I think what Chakra is doing here is technically fine. The 402 spec provides an API for the browser to handle internationalization, but it does not compel the browser to use the same formats as other browsers. Ideally, the spec would cause all engines to give the same result, but in practice that is a very difficult ask.

@LeaVerou is completely correct that Date().getHours() is inadequate. Because Javascript date can only reflect local time or UTC, it doesn't work for a broad range of use cases. This issue will ultimately be addressed in the temporal proposal. In the interim, if the results of this call were to become consistent across all engines, that would help the user move forward with a stopgap. Ultimately though, time zones are NOT a localization concern, and full support of all time zone related functionality can't fall to 402 to handle.

[LeaVerou]

If I read this correctly, the question is whether Chakra should give only the hour date part back when invoked this way.

Nope, it's two issues, as I mentioned above:

The issues here are that:
a) Minutes are reported, which is incompatible with every other browser
b) The reported minutes are wrong.

What you're saying is a, but there's also b.

And yes, what Chakra is doing is not a spec violation. However, I never claimed it was a spec violation. Not every browser bug is a spec violation.

[dilijev]

I agree with you that this is unfortunate, and will see if there's anything we can do under WinGlob, but I want to clarify a couple of things to inform the work:

a) Minutes are reported, which is incompatible with every other browser

I would say instead that minutes are displayed (when the expectation based on other browsers is that minutes should not be displayed) -- but, since it is a time, it makes some kind of sense to display it in a format which would be recognized as a time instead of a plain number.

b) The reported minutes are wrong.

No minutes information is selected, so there is no information to display and a reasonable default of :00 is used in the format template. IMO, given the information selected (no minutes), displaying anything other than :00 for minutes would be more incorrect. Although it would be easy to implement the "correct" minutes, there's no point to making a work item about displaying the minutes here, since we'd be adding incorrect behavior on top of an incompatibility (which is not incorrect according to spec).

I think point b is more an interpretation of a detail about issue a, and not really an issue in and of itself.

I'd say the actionable issue here is simply:

a) Minutes are reported, which is incompatible with every other browser

And we will try to fix this, if possible.

[dilijev]

Tracking as part of #3644