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!

[cbrnr]

Here's a quick summary:

• The current dev version shows "Last updated Oct 8, 2025 at 8:27:59 AM GMT+2" for me. I use an "en-US" locale with custom settings for the clock (24h) and other things (like metric units etc.).
• The 1.10 version shows "Last updated 2025-08-16 04:20 UTC", which is not localized (i.e., the same for everyone), but at least follows the ISO8601 standard.
• Browsers cannot extract 12h/24h clock settings, so people with an "en-US" locale will always get a 12h clock.

Therefore, I suggest reverting the timestamps to ISO 8601. However, instead of always showing UTC (e.g., "Last updated 2025-08-16 04:20 UTC"), I thought we could at least show the timestamp in the user's timezone (e.g., "Last updated 2025-08-16 06:20 UTC+2").

[cbrnr]

OK, the footer looks like this for me now (see here):

© Copyright 2012–2025, MNE Developers. Last updated 2025-10-08 11:42 UTC+02:00.

[cbrnr]

@drammock let me know if this works for you.

[drammock]

OK, after way too much time testing in a macOS VM with different browsers, I've convinced myself that there's really no way to get it to do what it was meant to be doing and still give @cbrnr a good result. As long as your browser's default/preferred language is en-US then you'll see a US-style datetime string from .toLocaleString() (regardless of any OS locale settings).

So I think the remaining decent options are:

date.toISOString(); // 2020-05-12T23:50:21.817Z
date.toUTCString(); // Tue, 12 May 2020 23:50:21 GMT
// pass in a hard-coded locale that is the same for everyone
date.toLocaleString("SE", { "timeZoneName": "short" }); // "2020-05-12 18:50:21 UTC−5"

IIRC the whole point of @larsoner's attempt to localize the datetime string was to get it in each dev's own timezone, making it easier to see "these docs were built last night" vs "these docs were built an hour ago" without needing to do mental time zone math. So I think that leads us to the hard-coded locale after all.

I acknowledge that I objected to this before, as imposing one person's format preferences on everyone. I still kinda feel that way, but in the end pragmatism wins because I think that (1) most people understand YYYY-MM-DD HH:mm:ss ZZZ even if it's not the default for their language, and (2) probably not that many people care about this anyway (only contributors) so forcing @cbrnr to either change his browser language or live with an unappealing en-US datetime format seems capricious.

[cbrnr]

Thanks @drammock! It's not that this is super important, but forcing me to interpret AM/PM time is indeed not ideal (is noon AM or PM?) 😄.

BTW, why did you go for SE? This gives me:

10/9/2025, 2:00:00 PM GMT+2

I think you need to pass the two-part full locale in order for this to work.

Previously I used sv-SE:

2025-10-09 14:00:00 CEST

This shows timezone names instead of offsets, but I like it. If you want UTC offset, I think we need to manually set the fields like I previously did.

[drammock]

why did you go for SE? This gives me:

That's not what I was seeing (as evidenced by the comment on the last line of my most recent code snippet). sv-SE is fine if that gives better results

[cbrnr]

I think the full locale (i.e., sv-SE) is needed, otherwise Javascript falls back to some default, which might explain why we were seeing different formats.

[cbrnr]

Does anyone know why these four jobs fail when installing the minimal commands?

gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now

[drammock]

likely a download error (from OSF), may be fixed by #13440