Stuck on an issue?
Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Chrome displays 24 instead of 00
See original GitHub issueDateTime.fromFormat("2020-06-12 00:00", "yyyy-MM-dd T").toFormat('T')
Result: 24:00
Expected: 00:00
Issue Analytics
- State:
- Created 3 years ago
- Reactions:4
- Comments:15 (4 by maintainers)
Top Results From Across the Web
Chrome 80 shows timestamp "24:xx" instead of "00:00".
In Chrome 80, 81(beta), timestamp which represents the time just passed midnight is wrong. Step to repro: Open console of dev tool.
Read more >Chrome not recognizing 24:00:00 while Firefox does
You are asking the browser to parse an invalid time. 24:00 isn't valid. You probably mean 0:00 of the next day. Chrome is...
Read more >Change between 24 Hours and AM/PM time
Chrome · Open the menu · Click Settings · Scroll down and click Show advanced settings. · Click Languages. · In the window...
Read more >24hr format instead of AM/PM in Europe - Configuration
Google chrome on a Windows machine at home shows 24 hour format - it is set to British English in both browser and...
Read more ><input type="time"> - HTML: HyperText Markup Language | MDN
It, like Chrome, uses a 12- or 24-hour format for inputting times, ... a <p> element with a <span> to display the value...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
TL;DR;
Chrome v80 introduced support for the
hourCycleoption inIntl.DateTimeFormat, which specifies if midnight should be displayed as00or24. However, locales using a 12 hour format by default (such asen-US) now display midnight as24when 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
hourCycleoption inIntl.DateTimeFormat.The four supported values are “h11”, “h12”, “h23”, or “h24” (MDN) and the difference between
h23andh24is precisely if midnight should be displayed as00(h23) or24(h24) (details).However, Luxon uses the
hour12: falseoption instead, which overrides the hourCycle option in case both are present (MDN). In that case, deciding which ofh23orh24to 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 inh24when requesting a 24 hour display.Note that no region defines
h24has 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 ofhour12: falsein 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.
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