Timezone +00.00 = UTC time https://en.wikipedia.org/wiki/UTC%2B00:00

9am UTC time = 11am Brussels time https://www.worldtimebuddy.com/?qm=1&lid=2800866,100&h=2800866&date=2024-4-20&sln=11-14&hf=1

What you're seeing here is intended behaviour, sort of. For online events (where a participant does not have to travel physically), we display the date and time in the user's preferred time zone, as that should be the most relevant to them. For instance, if I'm based in New York (currently UTC -4) and want to attend this event, I'm more interested in knowing its equivalent NY time (in your example, 5:00 - 8:00) to see if I can attend. When you are logged out, however, you can't set a preferred time zone, and therefore it falls back to the wiki's time zone; for meta, this would be UTC, hence that's what you see when logged out. Maybe, this might be improved by falling back to the event timezone when a user preference isn't available; curious to hear what @ifried @gonyeahialam think about it.

Do note, however, that the start and end time are never wrong. They're just shown in a different time zone.

Thanks for explaining, @Daimona!

@Geertivp and @Johannnes89, I'm curious to hear what you think of how we currently handle timezones. Do you think it makes sense, or would you suggest something else?

I'm fine with the way it currently is. But given that some people apparently don't realize that „Timezone: +00:00“ means UTC this could probably be added?

I like Daimona's idea of displaying the event timezone when a user preference isn't available, although this could also confuse users who browse through events in different time zones? Is it possible to use the browser time for logged-out users?

This is exactly the problem. When the user is not logged in, the browser timezone should be taken into account, instead of displaying just the UTC time. The user should not be required to manually recalculate the time.
There exists a JavaScript function to do so: https://stackoverflow.com/questions/6939685/get-client-time-zone-from-browser

const tz = Intl.DateTimeFormat().resolvedOptions().timeZone;
console.log(tz);

In T362639#9718140, @Johannnes89 wrote:

I'm fine with the way it currently is. But given that some people apparently don't realize that „Timezone: +00:00“ means UTC this could probably be added?

Yup, that is tracked in T325300 (not currently being worked on, but can be reconsidered).

I like Daimona's idea of displaying the event timezone when a user preference isn't available, although this could also confuse users who browse through events in different time zones? Is it possible to use the browser time for logged-out users?

Yeah, unfortunately the whole time zone thing is a huge mess (and I'm talking about life, not the event registration tool) and I'm afraid there's bound to be confusion no matter what we do. Still, I think using the browser setting should be doable, with the caveat that it wouldn't appear immediately on page load (you would get the "default" time zone for a split second, then it'd update to the browser setting).

Maybe display both the user timezone and the UTC timezone in a clear form: 10:00 CEST (8:00 UTC).

An other way could be: display the hour in the timezone choosen by the organizer + the user timezone (and get rid of the UTC). Example : 10:00 PDT (19:00 CEST)

Noting that this topics has come up again in some discussions, and we may want to look into improving the experience once we finish Invitation Lists work. Timezones such as 0:00 are especially confusing to newcomers who may not understand wiki conventions, and it is also likely that users would simply prefer to see the timezone of their browser.

Hey @Daimona! I am looking back at this ticket, since we're releasing to more wikis, some of which have large use bases in many different timezones... so I think this ticket is deserving of a refreshed look.

You previously commented that the user would first see the wiki timezone for a split second, and then it would switch to browser timezone. While this isn't the absolute best behavior (since best behavior would just be to *always* display the browser timezone), it is still preferable, I think, since we ultimately do display the timezone in a way that is understood by the user. If we were to implement the solution you have in mind, would this be relatively straight-forward technical work? Or would it still potentially be quite big/complex because it's still about timezones (and when is timezone work not complex?!?). Curious to hear your thoughts!

In T362639#10248546, @ifried wrote:

Hey @Daimona! I am looking back at this ticket, since we're releasing to more wikis, some of which have large use bases in many different timezones... so I think this ticket is deserving of a refreshed look.

You previously commented that the user would first see the wiki timezone for a split second, and then it would switch to browser timezone. While this isn't the absolute best behavior (since best behavior would just be to *always* display the browser timezone), it is still preferable

Unfortunately, I don't think we can do any better. The user browser's timezone can only be read from, well, the browser, and this in turn can only happen in JavaScript after the page has loaded. In principle, there are various way to mitigate that, but not resolve it completely.

If we were to implement the solution you have in mind, would this be relatively straight-forward technical work? Or would it still potentially be quite big/complex because it's still about timezones

The general concept is simple. We might find obstacles along the way (e.g., if some of the timezone formats we use aren't supported in JS) that are somewhat hard to predict offhand, but it shouldn't be too hard; mostly because the timezone is only shown while the user is reading the page, and then recomputed again on the next visit (without being persisted).

Thanks for this information, @Daimona! I'll think about this...

@ifried One thing I previously overlooked: we can't do this for the registration confirmation email. Email clients strip all JavaScript from the email content, and therefore we have no way to switch to the browser timezone. The best we can do is what we're already doing: trying to use the timezone set in Special:Preferences, and adding a clear indication of what timezone is used.

I'm also hoping that the timezone used in the email will become less important when we implement T351757: [EPIC] External Calendar Integration for Event Registration: as a participant, you could add the event to your calendar immediately (which would use the right timezone) and forget about the email.

Okay, thanks for this update, @Daimona. Not ideal because, yes, then we have the time displayed in one timezone on the wikis, potentially, and another timezone in the confirmation email. However, yes, I think we should probably still proceed with work for two reasons:

• We want to do this work overall so that people can easily know what time an event is happening, so they can decide if they want to join. This is a decision they make when reviewing the event page on the wiki. So, this is the most critical thing for us to fix first.
• Yes, we ultimately need to do the external calendar integration, so this should resolve the issue. However, my one concern is how we're blocked on this work -- are there any positive signs for us being unblocked any time soon, or no?

In T362639#10291290, @ifried wrote:

• Yes, we ultimately need to do the external calendar integration, so this should resolve the issue. However, my one concern is how we're blocked on this work -- are there any positive signs for us being unblocked any time soon, or no?

I think we just decided to put it on hold. For google calendar, there's an incompatibility with timezones that we weren't sure how to address (as it's a limitation on google's part). For simple ICS, I don't think we were blocked.

Yup, I remember that the limitation was something we just didn't know how to move forward with regarding Google Calendar. Anyway, we'll move forward with this work. Thanks for taking it on, @Daimona.

@ifried Sorry, I also overlooked another thing. Once we have computed the updated time and we're ready to show it, we need to format it (for example, dd/mm/yy or yyyy-mm-dd, or whether it should be 12h or 24h). Our current code uses the i18n logic in MediaWiki to format the time according to the user preferences, or to the wiki default preference as a fallback. However, this can only be used on the server side, before the page loads, and not on the client side after we've updated the timezone (see T21992, created in 2009...). This leaves us with ~3 potential solutions:

1. Pure client-side implementation: format the date according to the browser locale. The potential problem is that each locale can only have a single date format. This is surely better than nothing, but a bit limited: different people may prefer different formats within the same locale. See examples at the end of this comment.
2. Server implementation: once we have the new date and time, we just ask the server-side code to format it for us (with an API request). This way we don't have to worry about incompatibilities or limitations. The user will still see the date in their preferred format; and as a bonus, said format will be the same as before we update the timezone.
3. Hybrid client/server implementation: I'm including this for completeness, but I don't think it would actually work in practice. On the client-side, we could ask MW what's the preferred date format of the current user. We then use this information to format the date on the client. This should work for English and other languages, but I think some of the formats used internally by MediaWiki would be unsupported by the client code. In fact, MediaWiki probably has one of the best date/time localization systems in existence, supporting all sorts of calendars (besides Gregorian), localised digits/punctuation/grammar rules and whatnot. Other libraries, and particularly the ones we're using, don't have support for all the things that MW supports.

All in all, I'm leaning towards option #2, because it preserves the current format, and it's also more likely to support user preferences in all languages. However, I should also point out two potential downsides of it:

• We would still be relying on user preferences (or wiki default), especially for logged-out users. Still, I think it is more acceptable to do this for the date format than for the timezone.
• It would take a bit longer to display the updated date in the UI. The difference would probably not be noticeable with a fast connection. It might be more noticeable with slow networking. I assume this could also be acceptable?

Client-side format examples

For the client-side option, assume the date to be formatted is 2024-11-05 15:00. If the browser is set to English (or AmEng), we could choose between a few options such as 5 November 2024 3:30 PM (long month) or 5 Nov 2024 3:30 PM (short month) and potentially others. However, this choice is global, meaning it cannot be changed per-language, per-wiki, per-user, or per-page. It's going to be the same format everywhere, in every language, 100% of the times. We would be choosing the format for everyone.

Thanks for sharing this very thorough & informative breakdown, @Daimona!

I also think that option 2 probably sounds the best, especially for users who have chosen a preferred format for timezone. I have one question though: For users who are not logged in or do not have a preferred timezone format, would option 1 potentially be more likely to be a format they recognize, since it will be based on the browser locale rather than wiki default? Just trying to think through the differences in experience for logged in vs. logged out users a bit more... We can also discuss this in backlog refinement tomorrow.

In T362639#10294904, @ifried wrote:

For users who are not logged in or do not have a preferred timezone format, would option 1 potentially be more likely to be a format they recognize, since it will be based on the browser locale rather than wiki default?

That's a very good question, and I didn't include it above because I don't know the answer. I think it might depend on the wiki. In general though, I believe it shouldn't be too hard to figure out the format, since they're all similar; it's more a matter of personal preference for one format or the other. And this is unlike timezones, when there's a potential for ambiguity if you're not sure what timezone is being used.

Hi @Daimona, thanks for this detailed analyses, option 2 sounds good to me!

Change #1087894 had a related patch set uploaded (by Daimona Eaytoy; author: Daimona Eaytoy):

[mediawiki/extensions/CampaignEvents@master] Add internal REST endpoint to format date strings

https://gerrit.wikimedia.org/r/1087894

Change #1087915 had a related patch set uploaded (by Daimona Eaytoy; author: Daimona Eaytoy):

[mediawiki/extensions/CampaignEvents@master] Add TimeZoneConverter JS utility

https://gerrit.wikimedia.org/r/1087915

Change #1087959 had a related patch set uploaded (by Daimona Eaytoy; author: Daimona Eaytoy):

[mediawiki/extensions/CampaignEvents@master] Convert time(zone) in event page header

https://gerrit.wikimedia.org/r/1087959

Change #1088587 had a related patch set uploaded (by Daimona Eaytoy; author: Daimona Eaytoy):

[mediawiki/extensions/CampaignEvents@master] Use TimeZoneConverter in the event page "more details" dialog

https://gerrit.wikimedia.org/r/1088587

Change #1088589 had a related patch set uploaded (by Daimona Eaytoy; author: Daimona Eaytoy):

[mediawiki/extensions/CampaignEvents@master] Use TimeZoneConverter in Special:EventDetails

https://gerrit.wikimedia.org/r/1088589

Change #1087894 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Add internal REST endpoint to format date strings

https://gerrit.wikimedia.org/r/1087894

Change #1087915 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Add TimeZoneConverter JS utility

https://gerrit.wikimedia.org/r/1087915

Change #1087959 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Convert time(zone) in event page header

https://gerrit.wikimedia.org/r/1087959

Change #1088587 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Use TimeZoneConverter in the event page "more details" dialog

https://gerrit.wikimedia.org/r/1088587

Change #1088589 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Use TimeZoneConverter in Special:EventDetails

https://gerrit.wikimedia.org/r/1088589

For logged out users, this is functioning correctly. Phone browser set to Europe/Paris and laptop browser set to America/Chicago.

Event page registration header	Event page 'more details' modal	EventDetails

One question though @Daimona and @ifried , when I do not specify my timezone, it shows in preferences that it should default to the wiki default, in this case UTC. But then with this patch we have it overriding that to display event timezone in the browser default. Just checking to make sure this is correct behavior and if we should make some sort of note in the https://meta.wikimedia.org/wiki/Special:Preferences#mw-prefsection-rendering that the default behavior for timezone offset will not apply to the Campaign Events?

In T362639#10341627, @vaughnwalters wrote:

One question though @Daimona and @ifried , when I do not specify my timezone, it shows in preferences that it should default to the wiki default, in this case UTC. But then with this patch we have it overriding that to display event timezone in the browser default. Just checking to make sure this is correct behavior and if we should make some sort of note in the https://meta.wikimedia.org/wiki/Special:Preferences#mw-prefsection-rendering that the default behavior for timezone offset will not apply to the Campaign Events?

It is correct in my opinion. "Use wiki default" is the default preference value, which is equivalent to not having set a preference. Even in cases where the wiki default timezone matches the user's actual timezone (which is not uncommon for lots of language wikis), the browser timezone is presumably identical, and generally more reliable.

In T362639#10342078, @Daimona wrote:

In T362639#10341627, @vaughnwalters wrote:

One question though @Daimona and @ifried , when I do not specify my timezone, it shows in preferences that it should default to the wiki default, in this case UTC. But then with this patch we have it overriding that to display event timezone in the browser default. Just checking to make sure this is correct behavior and if we should make some sort of note in the https://meta.wikimedia.org/wiki/Special:Preferences#mw-prefsection-rendering that the default behavior for timezone offset will not apply to the Campaign Events?

It is correct in my opinion. "Use wiki default" is the default preference value, which is equivalent to not having set a preference. Even in cases where the wiki default timezone matches the user's actual timezone (which is not uncommon for lots of language wikis), the browser timezone is presumably identical, and generally more reliable.

Okay thanks @Daimona in this case, I am sending this to product sign off. @ifried let me know if you feel differently about this issue.

I confirm that the times are identical now, if I am logged in versus when browsing in a Private window (not logged in). Thanks for updating the Event tool.

That's great to hear, @Geertivp. Thank you for testing from your end and for using the tool!