Personal views:

1. I think "Browser-local time" should be a preference for "Time zone" and used only if that's the chosen setting. Could be the default setting, though for new users. Disclosure: I use UTC, not local time (possible bias).
   • Currently there's only a "Fill in from browser" option, that grabs the browser's time offset (that includes the current day-light saving) and stores as a setting. That setting does not follow day-light and timezone changes, therefore it's not really useful.
2. I often copy the date-time, including timezone to refer to specific comments/diffs or to search for the time in the history. For these usages consistency of the comment timestamps and history timestamp is important, both should follow the wiki preference.
3. Showing the relative time by default and the absolute time (wiki preference / UTC) on hover is common in messaging software and quite convenient in Flow. However, the tooltip popup solution of reddit is not so convenient imo.
   • It would be a nice feature to have with a setting that enables it (could be enabled by default for new users). Note: I actually don't use it, but I know editors who have some script to do this for talk page comments.
   • The user should be able to easily select and copy the absolute time. If the presentation changes on hover, there should be some padding to allow for the mouse pointer to move past the last character. Currently, in Flow the user has to stop moving the mouse precisely after the last (first) character.
4. Communicating using UTC in global communities is common. There should be an option to show the time in UTC zone on hover, regardless of the wiki preference and whether relative time is shown by default.

As discussed during today's team meeting, we will revisit this task part of v2.1 – T236918 – wherein we will focus on enhancing, "...the talk page read experience to help contributors more easily understand Talk Pages are spaces for discussion and how to participate in existing conversations."

1. Localized times will confuse and disrupt communication. We routinely use the timestamp when referring to a comment or edit. If you localize times the time value becomes randomized garbage for everyone trying to read it.
2. Displaying localized time would require deeply screwing around with how wikipages work.

(I thought I had already commented here weeks ago, huh.)

If we do local timezones, then we should use the timezone from the MediaWiki preferences, rather than from the browser. This is a long-standing feature request for MediaWiki (e.g. T46890, T27476). This approach should avoid the problem noted by @Alsee, probably many users would indeed prefer to see the "original" timestamp and that would be the default.

For many purposes though, displaying the relative time would be more useful than adjusting the timezone. (If someone posted a comment 2 minutes ago, I can reply now and expect their reply soon; if they posted it a day ago, they probably won't see my reply immediately.) Usually comparing current time to the time of the comment is easy enough, but it's a chore if you're in a different timezone than the wiki default, and why should we make the user do the math anyway?

But: I think both of those are less important than displaying the time in the user's language and date format. You might think that "8 décembre 2019 à 16:22" is easy enough to understand, even if you don't speak French. But not every month shares the origins of month names like English/French do (and a few other languages), and there are worse cases, e.g. "01:53, 11 เมษายน 2561" in Thai (also note the year, I'll leave the explanation as an exercise for the reader). There's also my personal annoyance of some month names in Polish and Czech being very similar but referring to different months (kwiecień = April, květen = May).

Could someone investigate what percentage of active editors have a custom value set for MediaWiki timezone preference? I could be mistaken, but I expect it would be very low. I found it painfully disruptive when I tried using it.

In T240360#5922708, @Alsee wrote:

Could someone investigate what percentage of active editors have a custom value set for MediaWiki timezone preference? I could be mistaken, but I expect it would be very low. I found it painfully disruptive when I tried using it.

I've seen in screenshots people using their local timezone, that's a reasonable use-case. I'm not sure that's what you mean by custom. Btw, I prefer UTC for archiving purposes, but that's a geek use-case, so I don't assume that's general.
Also, could you please use less dramatic and clearer wording? How can a setting that you enabled for yourself be "disruptive"? Maybe you mean annoying.

In T240360#5922708, @Alsee wrote:

Could someone investigate what percentage of active editors have a custom value set for MediaWiki timezone preference? I could be mistaken, but I expect it would be very low. I found it painfully disruptive when I tried using it.

Why is this relevant?

@Demian I don't understand your objection about being "less dramatic". What I said was mild, accurate, and factual. For what it's worth I'll try to clarify. When I set a Mediawiki timezone preference I found it was absolutely disruptive to my ability to work. I had to turn it off as soon as I encountered the problem. We copy-paste or type timestamps on a semi-regular basis, and it's a problem when they don't match the entries in history or other logs. Anyone who sets a timezone is going to have to manually convert any timestamp posted by anyone else before they can compare it it in history or logs, and they need to preform a manual conversion before they posting any timestamp. If they don't, other editors will complain about them posting invalid timestamps.

@Izno the reason to check Mediawiki timezone preference usage is to determine whether this Phab would have any meaningful use. You can't use browser timezone. A random user posting a timestamp has an effectively random time offset, so posted timestamps would be randomly corrupted for everybody trying to ready them. People would riot over the disruption. This task would have to use Mediawiki timezone preference, and this task won't do much if the preferences has effectively zero usage.

You know, you could just display both...

I imagine most people don't habitually convert UTC to their local time, since the vast majority of websites display local time, and some people just might not know how time zones work or something. If the intention were specifically to give new users a hand, I imagine you would ideally give them both by default (e.g. UTC always in small text after the local time, maybe using the ISO date format to distinguish it) and allow one to be hidden, since there are probably still going to be tools and interfaces that only display either UTC or the local time after the end of this project, and (as Alsee suggests) users communicating timestamps to each other would still need to use UTC.

Nevertheless, I would guess that most users don't actually copy and paste timestamps, so there might not be much disruption if the preference doesn't automatically change for existing users. If you don't get into a large discussion/conflict or e.g. report someone to AIV, there's just not much of a reason to do it (since you presumably would only do it where there would otherwise be ambiguity in referring to a specific edit or comment).

I don't think it makes sense to change the timestamp display upon hovering by default, since it could be difficult for users to discover this (particularly on mobile). I think it would be nice to have as an option, though. Similarly, I don't think the relative time should be the only string displayed by default, particularly if it isn't made clear whether the string is based on the current time or the time that the page was loaded.

Making a hover-based toggle could also make copying and pasting more difficult, although the need to copy and paste in some situations could be eliminated with other interface changes (e.g. adding automatic anchors and a "share" button).

In T240360#5929546, @Jc86035 wrote:

You know, you could just display both...

This, if there's space for it.

Nevertheless, I would guess that most users don't actually copy and paste timestamps

What we don't do often, still needs to be done. It's a necessity, albeit not a regular one to copy absolute timestamps and not "3 minutes ago".

In T240360#5929573, @Jc86035 wrote:

I don't think it makes sense to change the timestamp display upon hovering by default

That solution is quite common.

since it could be difficult for users to discover this (particularly on mobile).

Indeed, that won't be practically usable on mobile. It's more important on desktop, though. I'm thinking: how often do you copy timestamps - or anything - on mobile?

I think it would be nice to have as an option, though. Similarly, I don't think the relative time should be the only string displayed by default, particularly if it isn't made clear whether the string is based on the current time or the time that the page was loaded.

That sounds like a good option.

Making a hover-based toggle could also make copying and pasting more difficult, although the need to copy and paste in some situations could be eliminated with other interface changes (e.g. adding automatic anchors and a "share" button).

It can be done bad, indeed, like reddit using a tooltip that can't be selected.
In StructuredDiscussions it works well because it's not practical to select more than one timestamps at a time, so the one needed can be hovered while copying. Just move over it, click three times and CTRL+C.
On talk pages this might not be enough. I think the selection could be observed and the absolute timestamp shown when selected.

In T240360#5929725, @Demian wrote:

Indeed, that won't be practically usable on mobile. It's more important on desktop, though. I'm thinking: how often do you copy timestamps - or anything - on mobile?

It depends on one’s device usage customs. If mobile just augments a desktop/laptop computer, probably not often, as mobile is less suitable for editing. However, if one’s main device is a touchscreen one (it can be not only a phone, also a tablet/phablet), maybe even more than desktop users, as typing on a touchscreen keyboard is slower than on a phyisical one. Latter is common in the developing world (but also among children in developed countries).

I was talking to a French-speaking Quebec contributor editing on frwiki. And they confirmed what I'd never really taken the time to study: discussions are indeed the space where dates are not localized, whereas the rest of the interface is. They told me they do conversions manually, mentally...

Is it possible to study this functionality? I think it's important to study the time barrier. Especially for contributors who don't use the same time zone as the majority of wiki contributors. Also I think @matmarex is right, MediaWiki preferences should be used, rather than from the browser. DiscussionTools is already parsing the dates for the Reply tool, so the big job's already done?

If the ticket's priority is low, I might consider creating a wiki gadget, because I think the issue is quite important...