Luxon: Chrome displays 24 instead of 00

[kwtucker]

DateTime.fromFormat("2020-06-12 00:00", "yyyy-MM-dd T").toFormat('T')
Result: 24:00
Expected: 00:00

[GillesDebunne]

I'm unable to reproduce this problem (using firefox 79.0 or node 14.8.0 on OSX, with UTC or other timezone).

On which browser(s) or node version(s) does it happen?

[thomas-darling]

We encountered this too - it's because the locale data for the Intl API in the browser is wrong for some locales.
And it's worse than it appears - the time 00:15 is formatted as 24:15 too, which is just stupid.

I don't remember all the OS, browsers and locale combinations for which this occurs, but I just tested it again, and it definitely still occurs in Chrome 84 on macOS Catalina for the en-US locale. Here's a repro using the native API:

const formatOptions = { hour: 'numeric', minute: 'numeric', hour12: false };
const valueToFormat = Date.parse('2020-01-01T00:15:00');

const dateTimeFormat = new Intl.DateTimeFormat('en-US', formatOptions);
console.log(dateTimeFormat.format(valueToFormat));

// Outputs "24:15"

This really should be fixed in the browsers, but in the absence of that, it would be great if Luxon could include a fix.

[GillesDebunne]

TL;DR;

Chrome v80 introduced support for the hourCycle option in Intl.DateTimeFormat, which specifies if midnight should be displayed as 00 or 24. However, locales using a _12 hour_ format by default (such as en-US) now display midnight as 24 when asked to use _24 hour_ instead. This is a bug in the ECMA specifications, which should be fixed in ECMA2021.

Details

The root cause of this issue comes from this change in Chromium. It introduces support for the hourCycle option in Intl.DateTimeFormat.

The four supported values are _"h11", "h12", "h23", or "h24"_ (MDN) and the difference between h23 and h24 is precisely if midnight should be displayed as 00 (_h23_) or 24 (_h24_) (details).

However, Luxon uses the hour12: false option instead, which _overrides the hourCycle option in case both are present_ (MDN). In that case, deciding which of h23 or h24 to use in defined in this ECMA DateTime specification at §36, and depends on the _locale's default format_. For the _"en-US"_ locale, the default 12 hour AM/PM format (h12) results in h24 when requesting a 24 hour display.

Note that no region defines h24 has an allowed format and this clearly is a bug in the ECMA specifications, which should be fixed by this PR in the 2021 version. A Chrome bug report also tracks this issue.

Workaround

A workaround could be to use hourCycle: 'h23' instead of hour12: false in Luxon. However, since this option might not be supported, we should first run a fake format to detect if it is, and change all the formats accordingly?

[EDIT]]
The ECMA specification bug has been fixed, but Chrome still has the bug, even in its canary versions.

[kwtucker]

Another workaround is if you change the format from "yyyy-MM-dd T" to "yyyy-MM-dd HH:mm".

Current browser: Chrome Version 84.0.4147.135 (Official Build) (64-bit)
Luxon: "^1.22.2"

DateTime.fromFormat("2020-06-12 00:00", "yyyy-MM-dd HH:mm").toFormat('HH:mm')
Result: 00:00

[balagge]

Strangely, I get "0:00" (not "00:00")

Ubuntu 14
Node v12.18.3
[email protected]

[joshland96]

I'm seeing this as well on my local machine.

console.log(dateTime.toString())
console.log(dateTime.toLocaleString(DateTime.TIME_24_SIMPLE))

// Output:
// 2021-01-05T00:00:00.000Z
// 24:00

MacOS: 11.2.3
Node: 12.19.11
Luxon: 1.26.0