MAINT: Fix doc date

[larsoner]

Back in #7532 I broke the Last updated tag at the bottom of the website, and it has read "Last updated on 2020-03-27." ever since. With this PR I now get "Last updated 01/25/2021, 11:32 AM EST" and each person should get the equivalent datetime in their own timezone.

[drammock]

I have a fix for this already in #8757 that just uses one line in conf.py

https://github.com/mne-tools/mne-python/pull/8757/files?file-filters%5B%5D=.py#diff-e170e9a7d787c21095c6c11bb25f0f1ff0294a42a46d45ba6fb5ed794e457624R47

and one line in _templates/layout.html

https://github.com/mne-tools/mne-python/pull/8757/files?file-filters%5B%5D=.html&hide-deleted-files=true#diff-ee53b5b8ace34aceb7fd64220d4892db846fdf385d75b096628272fb1d02da8dR44

EDIT oh, I see you're actually doing the same thing, just with a bunch of (unnecessary?) javascript to put the last updated timestamp into the user's local time zone?

[larsoner]

EDIT oh, I see you're actually doing the same thing, just with a bunch of (unnecessary?) javascript to put the last updated timestamp into the user's local time zone?

Yes the difference is that the javascript localizes to both the user's time zone and their local date expression, which is to me much nicer than UTC's very long formatting in time zone that is often not the viewer's

[larsoner]

UTC's very long formatting in time zone that is often not the viewer's

I guess the long formatting only really matters if you include the time. I think it's nice to have in there as a dev but maybe users don't need it. And I guess we could localize the date at least, but this is probably a bit overkill since the YYYY-MM-DD format is probably okay, and weird stuff like the site showing an updated-date that is ahead of your actual date should be rare. So I can just change this to be your solution for a quicker merge to master and backport if you prefer @drammock ...

[drammock]

I'm starting to see the value of having the timestamp in there, for devs. WDYT about YYYY-MM-DD hh:mm:ss (basically follow ISO 8601 but replace T with a space) and always render time in UTC (no timezones)?

[larsoner]

Especially if it's for devs then having the timezone is useful, though. If I see some date in UTC I don't know the conversion immediately and I can never remember if it changes during the year due to daylight savings. Even if I teach myself the rules and internalize them then every dev needs to keep track of this if they want to actually know the date/time that something changed.

Another hint that this formatting is useful/standard is if you look at this commit on GitHub and mouseover the date that says "4 hours ago", for example on my machine it says "Jan 25, 2021 8:04 AM EST" not UTC. I'm assuming this is localized to each viewer.

[larsoner]

... looks like on GitHub this is done with:

<relative-time datetime="2021-01-25T13:04:35Z" class="no-wrap">Jan 25, 2021</relative-time>

and after the page loads something (presumably JavaScript?) adds a title="Jan 25, 2021, 8:04 AM EST" to get this mouseover effect. So we are really doing something similar to GitHub, just actually replacing the text itself rather than adding a title.

[drammock]

OK you've convinced me to accept the extra code for localized time. FWIW I'm seeing 01/25/2021 10:50 AM CST which may be the "standard format" in the country I live in but is definitely not my preferred way of seeing dates/times (I prefer YYYY-MM-DD and 24hr times).

[larsoner]

Looks like GitHub uses probably {dateStyle: "medium", timeStyle: "long"} because when I use this I get the same formatting as GitHub. If you don't like this formatting you can complain to your country's standards-setting organizations :)