If you use <input type=time>, the browser uses locale or user regional preferences… even if the app is in an application domain (e.g. medicine, military, science) where 24h is preferred even in 12h-predominant locales. There is no way for the app to say to the browser “this time field should be 24h in all locales”, the only option is to build a custom time field

I asked the HTML spec editors to fix this, but thus far they haven’t: https://github.com/whatwg/html/issues/6698

It gets worse.

Some browser APIs respect `LC_TIME`. Others say "fuck standards, I'm using `LC_MESSAGES`".

This means that if those locales differ about say, y/m/d ordering, it is quite possible for the way the browser formats a date to be different than the way it parses the date.

My issue is more with outputs than inputs (although the latter are also annoying to me in 12-hour format).

Operating systems generally allow user override of locale settings, and browsers generally respect that; I use a locale which officially has 12 hour time as its standard (Australian English), and I always override it to 24 hour time in user preferences (although Australia is rather inconsistent, e.g. in Sydney, train services use 24 hour time; in Melbourne, the metro trains use 12 hour time but the regional services use 24 hour time)

Interesting, so you're saying that that OS-level time preference is available via JavaScript? I wasn't able to figure out how to query that in a little bit of trying, so I assumed there was no API for it.

If there actually is, I'm now even more upset at that log web UI.

Well, if you run this Javascript:

    Intl.DateTimeFormat([],{"timeStyle":"medium"}).format(new Date())

It should return the current time, formatted according to your locale and user preferences.

By contrast, this should return it formatted with the defaults for your locale, ignoring your user preferences:

    Intl.DateTimeFormat(navigator.language,{"timeStyle":"medium"}).format(new Date())

For me, the first returns 24 hour time and the second returns 12 hour time. Because 12 hour time is default for my primary locale (en-AU), but I override it to 24 hour time in my macOS settings.

I know the same works on Windows, and I’m sure it works on Linux too, just the way you configure it is different for each OS.

> It should return the current time, formatted according to your locale and user preferences.

It does not for me! (I get 12 hour based time in Safari, Firefox, and Chrome, despite having 24 hours configured at the macOS system level.)

I have no idea what is going on then… works for me

maybe has something to do with OS or browser versions?

or maybe (for some reason) this works for some locales but not others?

That's interesting because I strongly prefer that timestamps are stored as UTC and converted to my timezone on the fly for easier debugging. I dunno about using the browser language choice (do sites really do this)? Usually a simple conversion with javascript is fine (javascript knows the local timezone).

A plus would be showing both.

I would especially like to call out the Scandic Hotels chain for this behaviour as well. Booking a hotel room should not involve me wondering if I booked it for the wrong day when I'm not in an European time zone.

My favorite example of that so far is the company that managed to shift my birthday by one day between their mobile and web apps.

That is the correct and only sane way to determine date format, timezone is not the same as formatting preference. But yeah it sucks. Assuming you're using the en-US locale, have you tried using the en-CA locale? It has ISO8601 formatted dates, and is otherwise pretty similar to the en-US locale.

In firefox you can try it out in about:preferences by setting en-CA as the topmost option in "Choose your preferred language for displaying pages"

And I just checked, firefox is capable of understanding system-wide split locale settings, if you only want LC_TIME

    localectl set-locale en_US.UTF-8
    localectl set-locale LC_TIME=en_CA.UTF-8

and dates will format, but currencies, addresses, etc will not

> That is the correct and only sane way to determine date format, timezone is not the same as formatting preference.

That's unfortunate, but then wouldn't the sane way for localization-aware software be to ask the user and not make any such assumptions?

> Assuming you're using the en-US locale, have you tried using the en-CA locale? It has ISO8601 formatted dates, and is otherwise pretty similar to the en-US locale.

Thanks, I'll give that a try tomorrow! If my log exploring UI of, well, not quite choice actually respects that, I'll be very grateful :)

In a way it is asking the user. Date formatting rules are traditionally tied to locale, so the user picks their locale and their expected date formatting rules are derived from that.

On Linux you can mix and match via LC_*= environmental variables, but that appears to be complexity the browser vendors didn't expose in their UI.

> That's unfortunate, but then wouldn't the sane way for localization-aware software be to ask the user and not make any such assumptions?

The sane way for any localization-aware software is to use the standard knobs that the user already has for setting such preferences. Which would be the appropriate LC_* in Unix and the corresponding user settings on Windows/macOS.

You can blame the browsers on that one. There is now an API to determine hour cycles, but it's not even supported in all browser yet:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Just a strong hint your fellow techdorks were being at work. Oh so clever, aren't they, always?