Luxon: Unexpected 24-hour time format in en-AU

Created on 17 Mar 2020  路  6Comments  路  Source: moment/luxon

In Australia (en-AU) a 24-hr time string to represent midnight is expected to be 00:00. However, 24:00 is returned.

For example the following returns '24:00'...
DateTime.fromISO('00:00').toLocaleString({ ...DateTime.TIME_24_SIMPLE, locale: 'en-AU' });

whereas the following return '00:00'...
DateTime.fromISO('00:00').toLocaleString({ ...DateTime.TIME_24_SIMPLE, locale: 'en-GB' });

As far as I'm aware Australia also commonly expresses midnight as 00:00 not 24:00.

Most helpful comment

@icambron We have been ignoring complaints about this issue in our app for a while now, and just today decided to deal with it. After reading this thread, and then a bunch of fumbling through Unicode documentation we found this table (see Day Periods at the very bottom) showing that the ICU has the correct data. However, Chrome, Edge, and Android all display the incorrect 24:XX, while Firefox, Safari, and iOS display the expected 00:XX.

Your fix to add hourCycle: 'h23' solves the issue in Chrome and doesn't appear to cause any issues with the browsers that already display the time correctly. That fix is also documented in the Google Chrome Help forum.

MDN describes the behavior we see in Chromium, but I don't see the ICU data supporting Chromium's choice to show h24 over h23.

We use Luxon a lot, and really hope to be able to leverage hourCycle to fix this time display. Regardless of what is correct for the locale, being able to show the time how we want would be very handy.

All 6 comments

Unfortunately, the ICU data disagree:

new Intl.DateTimeFormat("en-AU", { hour: "numeric", minute: "numeric", hour12: false }).format(new Date(2020, 03, 07))
"24:00"

Luxon doesn't control that; the ICU data do. So some expert somewhere thinks that Aussie 24-hour time uses 24:00, not 00:00. I couldn't say, but that's just how Luxon works.

A workaround for newer browsers is to use hourCycle to override what ICU thinks the rules in AU are:

DateTime.fromISO('00:00').toLocaleString({ hour: "numeric", minute: "numeric", hourCycle: "h23", locale: 'en-AU' });
"00:00"

Unfortunately, you can't use the preset because it includes hour12 and the docs for hourCycle includes this:

the hour12 option takes precedence in case both options have been specified

I will soon switch the presets to use hourCycle instead of hour12 and then you'll be able to do this:

DateTime.fromISO('00:00').toLocaleString({ ...DateTime.TIME_24_SIMPLE, hourCycle: "h23", locale: 'en-AU' });

Thanks for the explanation. Sorry, my searching skills are failing me, but where about in the luxon codebase are the locale-specific settings you pull in from the ICU data? Or is that something the browser is doing?

It's something browser is doing. Luxon uses the Intl API, like in my first code snippet above. Then the browser uses its data, typically taken from ICU, to provide the strings.

@icambron when are you going to add hourCycle ?

@Agranom I'm not sure. I need to evaluate how widely it's supported on browsers.

@icambron We have been ignoring complaints about this issue in our app for a while now, and just today decided to deal with it. After reading this thread, and then a bunch of fumbling through Unicode documentation we found this table (see Day Periods at the very bottom) showing that the ICU has the correct data. However, Chrome, Edge, and Android all display the incorrect 24:XX, while Firefox, Safari, and iOS display the expected 00:XX.

Your fix to add hourCycle: 'h23' solves the issue in Chrome and doesn't appear to cause any issues with the browsers that already display the time correctly. That fix is also documented in the Google Chrome Help forum.

MDN describes the behavior we see in Chromium, but I don't see the ICU data supporting Chromium's choice to show h24 over h23.

We use Luxon a lot, and really hope to be able to leverage hourCycle to fix this time display. Regardless of what is correct for the locale, being able to show the time how we want would be very handy.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

thetuyen picture thetuyen  路  4Comments

farnoy picture farnoy  路  3Comments

UnsungHero97 picture UnsungHero97  路  5Comments

kwtucker picture kwtucker  路  6Comments

Frondor picture Frondor  路  5Comments