Use timezone-aware ISO 8601 for website timestamp

[cbrnr]

I have set the language to English (US) and the region to Austria on my MacBook, but at least Chrome seems to ignore the locale settings and only uses the language to format the datetime. This means that despite of my locale settings, the timestamp is formatted as follows:

Jul 22, 2025, 10:55:44 PM GMT+2

This is the wrong date order, and it also does not use 24 hour time (despite my settings). I think it would be better to revert to the previous ISO 8601 based timestamp, with the difference that I now include the local timezone (instead of UTC).

[cbrnr]

Before:

After:

(I tried this at different times, but you get the idea.)

[cbrnr]

@drammock is there anything else you want me to do? The code is not using jQuery anymore.

[drammock]

sorry for the slow review. IIUC, what you're doing here is to hard-code the datetime style that you prefer, so that everyone sees that. To me that seems like a step backwards: the status quo is that date formatting follows the user's language setting. As far as I can tell, it is standard on the web to use language (not other aspects of the system locale) to determine date/time formatting (because in long forms, weekdays and months are spelled out as words, and in numeric forms some languages don't use arabic numerals). However, if you check your browser's console for

console.log(navigator.language);
console.log(Intl.DateTimeFormat().resolvedOptions().locale);

and they return different values, then I'm OK with passing the second of those to .toLocaleString() instead of sv-SE (and removing the customized options that you're specifying)

[cbrnr]

Let's try if this works. The current behavior is actually a step backwards, because it doesn't follow my locale settings. I do use an en-US language, but have other fields, including my datetime, set to en-AT or en-GB. The two commands return different values (en-US and en-AT/en-GB).

As a sidenote, ISO 8601 is not just some random format that I happen to prefer, that's the standardized format that I would use for consistency.

[cbrnr]

This doesn't work, not sure why, but I still get the US format.

[drammock]

This doesn't work, not sure why, but I still get the US format.

I am surprised. If I open my browser console and run:

const d = new Date("2025-08-14T18:27:46.531773+00:00");
d.toLocaleString('en-US');
// "8/14/2025, 1:27:46 PM"
d.toLocaleString(['en-AT', 'en-GB']);
// "14/08/2025, 13:27:46"

then I get clearly different results for en-US versus what you say your datetime locale settings are. Are you sure you're viewing the most recent CI doc build? Failing that, the only other possibility I can think of is that the use of const locale is causing problems, as there's a global var locale... but I don't see any console errors on page load, and given what I know about JS I'd expect it to be OK within function scope to redefine it.

The current behavior is actually a step backwards, because it doesn't follow my locale settings.

Prior to the purge of JQuery, it didn't follow your settings either. The datetime was starting out in ISO 8601 and then failing to localize, meaning everyone saw the same thing. In this PR, ec2d8e9 was returning us to that state --- where everyone sees the same thing. Localization that follows the user-set language (which seems to be what much javascript out there does) is better than that (in terms of the % of users who will see something that they like / can more readily interpret). Localization that follows the user-set datetime locale is even better, which is why I suggested it as a solution to your case (where the language and time locales differ).

As a sidenote, ISO 8601 is not just some random format that I happen to prefer...

Please don't act as if I don't know what ISO 8601 is. It's insulting.

...that's the standardized format that I would use for consistency.

If what you want is to use the standard (and force everyone to see that format) then why are you even mentioning your locale settings in the first place? Please clarify what you actually want: following your time locale, or always seeing the ISO 8601 form?

What I want is for users to see a localized version, according to their browser/system settings, with time zone. In 72be2bf we've lost the time zone, so I was wrong to say "purge all the options and just pass the locale" (paraphrasing); I'd like us to pass timezonename="short".

[cbrnr]

Was my initial explanation not clear?

[drammock]

Was my initial explanation not clear?

fair point; re-reading it you do clearly request to use (timezone-amended) ISO 6801. However, I still would like to know whether knowing now that localization was intended behavior that some users wanted, are you still requesting to force ISO 6801 on all users, or would you be content with localization that actually respected your settings?

[cbrnr]

I'd prefer consistent timezone-aware ISO for everyone. But if you don't like that, then at least the localized time string should follow my settings.

And I did not mean to be disrespectful, I read your comment as saying that I just want to enforce my locale settings on everyone.

[cbrnr]

I'm going to be offline for the next three weeks, so let's continue the discussion then!