> 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 :)
> 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.
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.