Update: I have talked with 2 of the ambassadors so far. Antoni recommended that we include both the organizer and participant timezone for hybrid events. @Bachounda recommended that we just pick one timezone for hybrid events. The ambassadors will be looking into getting more feedback from people on this topic.

Also pinging @Geugeor, @Sadads, and @IBrazal to get their opinions. Thanks!

Moving back to backlog since this ticket is in discussion

In T316688#8211840, @ifried wrote:

Update: I have talked with 2 of the ambassadors so far. Antoni recommended that we include both the organizer and participant time zone for hybrid events. @Bachounda recommended that we just pick one timezone for hybrid events. The ambassadors will be looking into getting more feedback from people on this topic.

Also pinging @Geugeor, @Sadads, and @IBrazal to get their opinions. Thanks!

Hi, these are my recommendations:

• For logged out users: Use the wiki's time zone
• For logged in users: Use the user's time zone
• For in-person events: Use the user's time zone,
  • indicating the time zone, e.g. UTC +8:00, UTC +1:00 (in this case user will be reminded of the time zone they set) and
  • with an option to view the actual time and place where it is happening
• For hybrid events: Use the user's time zone
  • with the option of All time, All day for Organizers
• (Not sure if this is possible) If we can detect that the time zone is not set, we can send a reminder to set a preferred time zone

I favor the dual timezone situation: with both organizers and local timezones -- we are seeing a lot of cross-geography events in the movement, and I think with the pandemic et-al we are going to continue seeing the need for that kind of cross time zone coordination

Exploring ideas for showing organizer and participant timezones

Note: To reduce confusion, we may want labels to show local timezone of event and your timezone preference. We can also maybe show a link to a website to 'show this event in my timezone.'

Key points from today's discussion

• In the prototype above, the timezone and the time are separated because by default, the time comes before the date, unlike on other event platfoms and such. Hence, putting the timezone at the end, far from the time, could be confusing.
• Counterargument: "time before date" may be the default for English, but doesn't have to be the same for other languages. Two random examples where the time comes after the date (look at the signatures, which use the wiki's default format): jawiki, zhwiki.
• Big difference between MediaWiki and other sites: we care a lot about i18n/l10n; google "most translated websites" to understand what I mean.
• Users can also decide how they want the date to be displayed, and it would be nice if we could respect that. The allowed formats depend on the language, see here for a list of preferences, and here for the list of defaults. I personally cannot possibly fathom the differences between all the formats that we support, but I can give you a simple example for English (this is NOT an actual example for the specific problem at hand, it's just meant to simplify things): imagine you could choose between day/month/year and month/day/year. If we hard-coded either format for the event time, it would be VERY confusing, and very hard for you to figure out which one was used. At most we could stick with the wiki default (instead of forcing "dmy, hh:mm" for everyone), but you still have no guarantee about the order of date and time.
• All in all, the problem here boils down to proper language support. This is already a super-complex topic, and we're mixing it with another equally complex topic, time. It's very hard to come up with a perfect solution, but we can try.

With that being said, we have a few options. The following were mentioned in today's meeting, but there could be more.

• Separate the timezone and the datetime, like in the prototypes above. This option is OK in general, but it cannot be backed up by an argument like "we're putting the timezone at the beginning because the time is also at the beginning". As outlined above, that's true for English, but no guarantee for other languages.
• Format the date according to the wiki's default, rather than user preferences. This is subpar, because it doesn't really solve any problem. You still have no guarantee that the time will come before the date. What makes this not entirely bad is that the default format is probably something that users are already used to (because it's language-specific and used for signatures etc.), but I don't see any reason to choose that over the user preference.
• Use a fixed format for the date, like "d M Y, HH:mm:ss". This is bad for usability, because you're forcing a format that users may not be used to.
• Show date, time, and timezone separately. This can be good or less good depending on how it's implemented, and the "degree" of separation. If you're still putting them in the same sentence, we're back to i18n problems (how do you "glue" the pieces back together? this is very closely related). Separating the pieces in something like a list could be a better approach, but then a potential concern would be UX clutter. An example of this approach could be:

Date: 15 August 2022
Time: 15:30
Timezone: Europe/Berlin

• One thing to consider for all the approaches above is adding labels like "event time" and "your time", but this can probably be done easily for all approaches, and I don't see any particular i18n-related risks for that.
• Another option is to show only the "event time", with a link to a time converter that you can use to convert it into your local timezone. That way we wouldn't have to show two separate date and times. You can find an example of this in the Wikimania program, where all times are UTC with a link to https://zonestamp.toolforge.org/ for the conversions. This could be a good solution for UX clutter, but it has an additional cost for the user (opening a separate web page to see the local time), and I'd like Gregory to weigh in on this aspect. Also, and perhaps most importantly, it does not completely solve the issue with timezones: even if we only display a single date+time, we still need to display which timezone it is in, and the i18n-related concerns outlined above are still valid for that case. However, maybe there would be more design flexibility if we're just displaying a single date+time.

Finally, I'd like to reiterate that from a purely technical perspective, all these approaches are doable. This is not really about what's possible technically, but rather what would work best for users, across 440 different languages. I would like for this to remain a collective discussion, because as an engineer, I don't, and shouldn't, have any prerogatives for what concerns i18n support.

Summing up, here are the

Recommendations

• Since the main focus here is on i18n and supporting all languages, I would like the participation of a language expert in this conversation. I believe that could help us all reach an informed decision.
• We should try and respect the user preferences for date format. I know this means it's more difficult to reason about all the possible scenarios, but I do think it's worth spending some time on it.
• In choosing a solution, we should keep in mind that we need to show the timezone even when there's a single date&time. See notes at T311138.

In T316688#8253646, @Daimona wrote:

Key points from today's discussion

• In the prototype above, the timezone and the time are separated because by default, the time comes before the date, unlike on other event platfoms and such. Hence, putting the timezone at the end, far from the time, could be confusing.
• Counterargument: "time before date" may be the default for English, but doesn't have to be the same for other languages. Two random examples where the time comes after the date (look at the signatures, which use the wiki's default format): jawiki, zhwiki.
• Big difference between MediaWiki and other sites: we care a lot about i18n/l10n; google "most translated websites" to understand what I mean.
• Users can also decide how they want the date to be displayed, and it would be nice if we could respect that. The allowed formats depend on the language, see here for a list of preferences, and here for the list of defaults. I personally cannot possibly fathom the differences between all the formats that we support, but I can give you a simple example for English (this is NOT an actual example for the specific problem at hand, it's just meant to simplify things): imagine you could choose between day/month/year and month/day/year. If we hard-coded either format for the event time, it would be VERY confusing, and very hard for you to figure out which one was used. At most we could stick with the wiki default (instead of forcing "dmy, hh:mm" for everyone), but you still have no guarantee about the order of date and time.
• All in all, the problem here boils down to proper language support. This is already a super-complex topic, and we're mixing it with another equally complex topic, time. It's very hard to come up with a perfect solution, but we can try.

With that being said, we have a few options. The following were mentioned in today's meeting, but there could be more.

• Separate the timezone and the datetime, like in the prototypes above. This option is OK in general, but it cannot be backed up by an argument like "we're putting the timezone at the beginning because the time is also at the beginning". As outlined above, that's true for English, but no guarantee for other languages.
• Format the date according to the wiki's default, rather than user preferences. This is subpar, because it doesn't really solve any problem. You still have no guarantee that the time will come before the date. What makes this not entirely bad is that the default format is probably something that users are already used to (because it's language-specific and used for signatures etc.), but I don't see any reason to choose that over the user preference.
• Use a fixed format for the date, like "d M Y, HH:mm:ss". This is bad for usability, because you're forcing a format that users may not be used to.
• Show date, time, and timezone separately. This can be good or less good depending on how it's implemented, and the "degree" of separation. If you're still putting them in the same sentence, we're back to i18n problems (how do you "glue" the pieces back together? this is very closely related). Separating the pieces in something like a list could be a better approach, but then a potential concern would be UX clutter. An example of this approach could be:

Date: 15 August 2022
Time: 15:30
Timezone: Europe/Berlin

• One thing to consider for all the approaches above is adding labels like "event time" and "your time", but this can probably be done easily for all approaches, and I don't see any particular i18n-related risks for that.
• Another option is to show only the "event time", with a link to a time converter that you can use to convert it into your local timezone. That way we wouldn't have to show two separate date and times. You can find an example of this in the Wikimania program, where all times are UTC with a link to https://zonestamp.toolforge.org/ for the conversions. This could be a good solution for UX clutter, but it has an additional cost for the user (opening a separate web page to see the local time), and I'd like Gregory to weigh in on this aspect. Also, and perhaps most importantly, it does not completely solve the issue with timezones: even if we only display a single date+time, we still need to display which timezone it is in, and the i18n-related concerns outlined above are still valid for that case. However, maybe there would be more design flexibility if we're just displaying a single date+time.

Finally, I'd like to reiterate that from a purely technical perspective, all these approaches are doable. This is not really about what's possible technically, but rather what would work best for users, across 440 different languages. I would like for this to remain a collective discussion, because as an engineer, I don't, and shouldn't, have any prerogatives for what concerns i18n support.

Summing up, here are the

Recommendations

• Since the main focus here is on i18n and supporting all languages, I would like the participation of a language expert in this conversation. I believe that could help us all reach an informed decision.
• We should try and respect the user preferences for date format. I know this means it's more difficult to reason about all the possible scenarios, but I do think it's worth spending some time on it.
• In choosing a solution, we should keep in mind that we need to show the timezone even when there's a single date&time. See notes at T311138.

Thanks, @Daimona, +100 to everything you mention!
At least for now, I like the option to display Date, Time and Timezone separately, I am a terrible design, but I added some images of what I mean, off course it does not need to look like the images below, it is only to illustrate what I mean.

{F35529744}

{F35529745}

We have made a final decision, after meeting with the team today. The decision is:

• Organizer-specified timezone for in person events
• Participant timezone for online events
• Participant timezone for hybrid events

Next steps:

Can we display the timezone in the event page with abbreviations rather than with the name of the location?

First choice: abbreviations (such as UTC, CEST, etc)
Second choice: open to options proposed by engineers

@ifried Which of the options was selected? Or were all three selected?

In T316688#8312246, @ifried wrote:

Final decision, after meeting with the team to discuss today:

• Organizer-specified timezone for in person events
• Participant timezone for online events
• Participant timezone for hybrid events

@Iflorez you will see that each bullet-point is for a different event type. all 3 were selected for different event types.

In T316688#8312246, @ifried wrote:

We have made a final decision, after meeting with the team today. The decision is:

• Organizer-specified timezone for in person events
• Participant timezone for online events
• Participant timezone for hybrid events

Next steps:

Can we display the timezone in the event page with abbreviations rather than with the name of the location?

First choice: abbreviations (such as UTC, CEST, etc)
Second choice: open to options proposed by engineers

Thanks, @ifried, did we decide how the design will look like? I mean the wireframe options shared on the task.

@cmelo I think how we display the timezone (in terms of the UX) depends on the formatting of the timezone. For example, if the format is something like 'America / New York' it may make sense to have a separate line for 'Timezone,' since that clearly conveys that 'New York' applies to the timezone and *not* the event location. If we have an abbreviation (such as EST), then it may be less necessary to have a separate line. So, once we know what is possible in terms of formatting, we can make a design determination.

Here is the website I use to figure out timezones. It shows the place, and the timezone abbreviation (EAT, GMT, GMT +1, etc) above. Inspiration for the designers @gonyeahialam
https://www.worldtimebuddy.com/

Just to clarify, I'm writing a (very long) comment for this task to explain what options we might have. I started yesterday, but I will need more time. Hopefully it's ready by EOD today.

FTR, I don't know why the comment above was published; I realized just now, 24 hours later, and I have no idea how it might have happened. I'm sorry if you read it (and angry at phab, and again sorry for the spoilers), but it looked like an older draft, so quite incomplete, most probably wrong, and certainly shorter than the final version. Speaking of which: after a few back and forths, I almost finished it. This time for real, I hope.

In T316688#8312246, @ifried wrote:

Can we display the timezone in the event page with abbreviations rather than with the name of the location?

First choice: abbreviations (such as UTC, CEST, etc)
Second choice: open to options proposed by engineers

I looked into this, and it's more compl— WHY am I even telling you, we're still in the territory of time and time zones, of course it's more complicated than it seems :D So let's take a step back and talk about time zones, how they can be represented, and how we use them. But beware: it's going to be a long journey.

Time zone representations

Generally, time zones can be represented in 3 different ways (referred to interchangeably as "representation" or "formats"):

1. As a geographical zone (e.g., "America/New_York" or "Europe/Rome"); see full list on enwiki
2. As an offset from UTC (e.g., "-03:00" or "+05:45"); see the list on enwiki
3. As an abbreviation (e.g., UTC, PST, CET); see the full list on enwiki

Wikipedia also has a short section about time zone notations, where it explains that ISO 8601 is the international standard for time representation. ISO 8601 defines two possible time zone identifiers: "Z" (for UTC), and offsets. Note that it's not clear whether we should care about ISO in our case. ISO 8601 prescribes the representation of a full date+time+tz value, but we only need to format either the time zone alone, or date+time in a human-readable way (so not ISO 8601).

The same section proceeds to explain that time zone abbreviations are potentially ambiguous and their use as time zone designators is discouraged. The list of abbreviations provides examples of ambiguity (like CST identifying 4 different time zones) and more context on that. Additionally, there doesn't seem to be an official list of time zone abbreviations [1]. This also means that it's unclear whether abbreviations could be translated and how. The source used on the Wikipedia article also provides some more abbreviations, including military zones (represented by a single letter).

One important note: unless stated otherwise, in the rest of this dissertation I will assume that we would always disambiguate time zone abbreviations as appropriate in our application, e.g., by using their full name. Thus, even when I write "abbreviation", I actually mean "disambiguated abbreviation".

As for the geographical format: that is what the Olson database (aka tz database, aka IANA database) uses. It's a popular format amongst computers [2], but not part of any ISO standards TTBOMK. This format has high specificity and low ambiguity.

One final note about representations: in the rest of this dissertation, I will intentionally not address i18n/l10n concerns. As I've already written about this in T316688#8253646 and T311138, language support is not too simple in this case (due to the variety of formats, translating time zone names, combining time and time zone in a way that makes sense for all languages, regardless of the time conversion, etc.). However, since time zones are already complex enough without languages in the way, for this dissertation I'm going to assume that whatever we choose to implement, we will either find a way to also make it translatable and sufficiently pretty in every language, or leave it in English.

And before you ask, yes, there are more representations besides the ones listed here. However, they're not well supported in PHP. Paraphrasing what a wise man once said, «all we have to decide is what to do with the time zones that are given us».

Where we need time zones: status quo

Before explaining the details of each format, I think it's very important to mention the status quo, given what's coming below. The CampaignEvents extension deals with time zones in the following places:

1. Form field filled out by the organizer when enabling/editing registration
2. API for enabling/editing registration
3. Value stored in the database, based on what the organizer entered
4. Script that updates the UTC timestamps when time zone rules change, based on the value in the database
5. Several parts of the interface for displaying the event time, based on the value in the database

The status quo is that the form field allows organizers to enter time zones in the geographical and offset formats, and the API supports all three formats. The database stores the time zone in whatever format was used by the organizer, provided it's valid. The script can read every format, but will only update records in the geographical format (more on this below). And finally, we're not showing the time zone with the event time yet; in fact, that's one of the goals of this task.

There's one subtle but key detail to keep in mind here: when editing an existing registration, the time zone selector needs to show the current time zone of the event (taken from the database). Since the time zone can be specified as an abbreviation via the API but the input field does not support abbreviations, we currently convert them to offsets. This is mostly correct, more about it later.

Another thing to note is that the time zone entered by the organizer would be used for both the start and end time. Technically it would be possible to have two separate time zones for the start date and the end date, but I'm not sure if this would be a good user experience. This idea will also be discussed briefly in a later section.

So the first question could be if we should instead only support a single format, and use it everywhere. In order to make a decision, we'll need the classic pros and cons.

Details, pros, and cons of each representation

Geographical

The Olson database defines a time zone as «any national region where local clocks have all agreed since 1970» [3]; thus, each geographical time zone is bound to a location with internal consistency over time.

Pros

• Each time zone uniquely identifies a geographical area; thus, if you know where the event will take place, there's one and only one correct time zone for it.
• The time zone of a place does not change over time (almost, see below); for instance, an event happening in Rome will always be in the Europe/Rome time zone.
• We can easily tell if the time zone rules for a geographical area changed, and update the derived UTC times if needed.
• Users may already be familiar with this representation, because it can also be selected in Special:Preferences.

Cons

• The time zone of a place can actually change: a city could be moved to a different time zone. This is more likely if the country observes multiple time zones and the city is near the edge of a zone. There isn't much we can do about it, unfortunately.
• Users may be unfamiliar with these names, and as noted in the documentation of the Olson db itself:

Inexperienced users are not expected to select these names unaided. Distributors should provide documentation and/or a simple selection interface that explains each name via a map or via descriptive text like "Ruthenia" instead of the time zone name "Europe/Uzhgorod".

• In part as a consequence of the above, users may think that a geographical time zone implies something about the location of the event. For instance, Philadelphia is in the America/New_York time zone, so someone could think that an event that is happening in Philadelphia may actually happen in New York, or things like that.

Offset

These can be specified in a few different ways ("+02:00", "+0200" and "+02" are the same thing), but this shouldn't really matter to us as it's only about the display. Also, only offsets between -12:00 and +14:00 are used in practice [4], and only multiples of 15 minutes [5]. However, in principle there's nothing wrong with using "+99:05" as offset, and we also wouldn't have any problem with it, so we don't need to worry about it here. But do feel free to limit offsets to those values, if you think it could help you understand these concepts. Finally, offsets are "absolute", and independent of humans and their decisions, so they never change over time, for better or for worse.

Pros

• These are standard ISO 8601 identifiers; I'm not sure if this counts as a pro for our use cases, though.
• If you see an offset, you can easily and quickly convert between UTC time and local time with simple math, without having to know about abbreviations or geography, or using any tool.
• Immutability is partly a pro: offsets are not affected by DST changes, so if you want the event time to be UTC+2, regardless of what happens in your country, an offset will guarantee that.

Cons

• As anticipated, immutability can also be a con: if you need the time to change with DST, offsets are not a good option. If, instead, you want the local time to be immutable, and also to use offsets, then you have to manually update the offset to account for DST and any changes to time zone rules.
• To users, it may not immediately be obvious what an offset corresponds to, compared with their local time. This is particularly true if you live in a country that observes DST, and the event also happens in a country that observes DST: you may know an approximate time difference between your country and that where the event happens, but probably not the exact difference on a given day. As a case in point, I know that Rome is generally 5 or 6 hours ahead of New York, but if you ask me what the time difference is today, or on January 15, 2023, I will have to look it up.

Abbreviation

I think they may not need an introduction, as you're probably familiar with them.

Pros

• As I just said, users are probably familiar with them. In particular, if you've ever participated in an on-wiki discussion, you may have seen time zone abbreviations in signatures.
• Their compactness, and the fact that they don't contain symbols or numbers, make them more easier for people to use.

Cons

• There's no standardized list of time zone abbreviations. This also means that different systems (for instance, PHP and JavaScript) may recognize different sets of abbreviations. It also mean that we may have to build and maintain a list of accepted time zones.
• As anticipated, abbreviations are ambiguous: what does CST represent? There are some obvious solutions to this: use the full name ("Central Standard Time", "China Standard Time", ...), or add the offset after the abbreviation ("CST (UTC-6)", "CST (UTC+8)"). In both cases, I believe there's a potential for UI clutter, especially if the time zone comes after a full date and time.
• Abbreviations change with DST. New York can be EST or EDT, central Europe can be CET or CEST, and so on. This may not be a problem when displaying the time(zone) of an event, but could become a problem for organizers who need to pick a time zone: would they have to choose between the DST and no-DST version themselves? Wouldn't it be confusing to include both? And what if they get it wrong? Or should we just automagically choose the right one? In this case, which option(s) would we show in the form? And how would we explain the difference between what the organizer selected and what is later shown in the interface?
• Abbreviations group together areas that may not agree on time zones. For instance, central Europe uses CET/CEST, but there are many states in that area. The EU parliament approved a directive that would let each member state decide whether to observe DST [6]. I would say that changes to the "country -> abbreviation" mapping are more likely than changes to the "country -> geographical" mapping, because geographical zones are smaller and can be expected to remain internally consistent over time.
• In part as a consequence of the above, if we let the organizers enter an abbreviation, we have no ways to account for future time zone changes affecting the region where the event takes place. Making such adjustments is part of the plan we devised for DST support, see T316687 and T314871. This is an intrinsic limitation of using time zone abbreviations: "CET" (or "CEST") conveys less information than "Europe/Rome". Let's say the organizer chose "CET", and then all of Italy (and Rome in particular) moves to a different time zone. The updated Olson database would tell us that Rome is now in a different time zone, but we wouldn't be able to update the UTC time of the event, because as far as we know it might be happening in any other state which uses CET and is not Italy. More about the geographical <-> abbreviations relation in a later section. At any rate, this may or may not be a problem, but the interface should explain that if you select an abbreviation, the time will not be adjusted if time zone rules change. Related: T320866.
• Since the time zone is used for both the start and end time, the abbreviation may not be a good choice if the event happens at the same time as a DST switch. Like, the event starts when Rome is in the CET time zone, and ends when it is in the CEST time zone. In this case, I think there's some potential for confusion.
• Technically speaking, it's unclear how good PHP's support for abbreviations is. The manual lists the supported time zones (only geographical) and then says that «The behavior of timezones not listed here is undefined.». This probably includes abbreviations, but presumably not offsets? It's also unclear what "behaviour" means, i.e., whether there are at least some features that are guaranteed to work even with time zones not listed here. And actually, after reading bug 74671 I'm under the impression that the PHP maintainers themselves may not know the answers to these questions.

And the winner is...

As I have said multiple times in the past, all non-trivial questions have the same answer: «it depends». In this case (as in many others) there's no "best" and "worst", or "right" and "wrong". All options are viable, and which one to choose depends on the product requirements, as well as the compromises we're willing to make. Some options may be better from an end user perspective, others may be more accurate.

I don't feel like giving any recommendations here. My goal with this dissertation is to make sure that we have a clear understanding of the problem(s), and to present the options we have, each with its pros and cons. Moreover, what I'm writing here has very little to do with technical difficulties and approaches, and it's more about usability and correctness. As such, my recommendations wouldn't be more important or valuable than those of any other person who has at least a basic understanding of the topic. Giving you that knowledge is one of the ambitious goals of this dissertation.

Using different formats in different places

While reading the pros and cons above, you may have noticed a leitmotiv: the suitability of each representation depend on the context, viz., whether we're using it for the form field used by the organizer, or for displaying a datetime in the interface. You may have asked yourself: «Then, can we use different representations in different places, converting between them as appropriate?». If you read the previous section, you should know the answer already. This is a good question though, and perhaps a more reasonable approach than the initial proposal of using a single format everywhere. Therefore, let us spend some time considering the interoperability of the 3 representations.

Time zone conversions

The title of this section is somewhat vague, and for good reasons: there can be many ways to convert time-related entities, and we're not interested in all of them. The conversions that we do care about are the ones where a given time zone can be transformed into another time zone in a given representation. Making distinctions here is very important, because the risk of getting it wrong is high. You may think you have a good understanding of these concepts, and by the time you realize that you didn't, you have already written a long section about conversions that you will have to rewrite from scratch. Then again. And again. And again. Obviously, this is not what happened here *cough*.

Use cases

At this point, it's a good idea to look at the application and its use of time zones again, and make a list of places where conversions may be necessary. Roughly 1800 words ago I explained where time zones are used, and where they are read from; now we can say that conversions can only happen when going from one place to another. Additionally, here we should not assume what formats are currently used in each place, because figuring out what format(s) each step could possibly use is one of the goals of this dissertation. So here are our us cases for conversions:

• Form -> database: the organizer enters a time zone in the form, in any format supported by the input field. We need to convert it to a format accepted by the database.
• Database -> form: the time zone in the database can be in any format, and we need to convert it to a format accepted by the form field.
• API -> database: we need to convert the time zone provided by the client to a format accepted by the database.
• Database -> script: as explained above, the script updates the UTC time only if the time zone is in the geographical format. Thus, whatever is in the database would have to be converted to geographical for the script to do its job. Note that in this case, it's fine if we're not able to convert a time zone. However, it also means that the stored value won't change if there's a change in the time zone rules.
• Database -> interface: this one is a bit more complex. First, according to our final decision (T316688#8312246), sometimes we will need to use the event time zone, and other times the participant (or wiki) time zone [7].
  • If using the event time zone: we can choose to either use whatever time zone was entered by the organizer, or convert it to a specific format. In the first case, no conversion needs to happen. In the second case, the time zone in the database should be converted to a predetermined format.
  • If using the participant time zone: we need to convert the value in the database to whatever value the user has in their preferences. In particular, user preferences only allow you to choose between geographical and offset. If we want to use a predetermined format in this case as well, we would have to convert the value twice: database -> user preference -> predetermined format. Note that the database -> user preference one is different from all other conversions: here we need to convert the value not to a given format, but to a given, specific time zone (the one set in the preferences, which may or may not be in a format other than the initial one).

Here's a diagram that illustrates this flow:

All that glitters is not gold

In that previous section about the status quo I also mentioned that the same time zone is used for both the start and end date. Unfortunately, this has an important effect on the conversions above: in some cases, the time zone resulting from the conversion needs to remain valid for both the start and end date. I will explain this in more detail, but here's a simple example of what I mean: let's say the original time zone is Europe/Rome and we want to convert it to a UTC offset. The result could be +01:00 or +02:00 depending on the date; this becomes a problem if the event starts while Europe/Rome is +1 and ends when it's +2 or vice versa. Thus, it's not possible to convert the original geographical time zone to a UTC offset independently of the date, and so that the end result is valid for both dates. For completeness, note that DST is not the only thing that could make conversions dependent on the date: for instance, Moscow Time was changed twice between 2011 and 2014, and that had little to do with DST.

With that in mind, it's important to determine what conversions in the list above need to produce a result that remains valid for both dates. Let's go through the list again:

• Form -> database: yes, whatever we put in the DB must be valid for both dates because we only store a single time zone.
• Database -> form: yes, the value to display in the form must be valid for both dates because there's a single time zone selector.
• API -> database: yes, same as the form.
• Database -> script: no, the conversions are done separately for each date, so we can have two (different) results.
• Database -> interface:
  • If using the event time zone: no, we convert the start and end time separately.
  • If using the participant time zone: no, we convert the start and end time separately.

I also want to reiterate that the database -> user preference conversion is unique, because we're not really going from one time zone representation to another, but from a time zone to another. Since we'd be doing that for the start and end date separately, the conversion is always possible, and we don't need to discuss it here.

All in all, this leads us to a second version of the diagram above:

Blue arrows represent conversions that must be valid for both dates, green arrows are conversions that only need to be valid for a specific date, and the grey arrow is a conversion we chose to ignore.

As anticipated a while ago, the underlying question here is: could we have one time zone for the start date and one for the end date? Surprisingly, the answer may as well be yes. It would add some technical complexity—not much, though. In fact, the main risk would be UX clutter. Having two separate fields for the time zone may already be confusing. And it'll get worse when adding support for multiple dates (T318171), because then we would need one time zone selector for each date. There might be ways to mitigate this, like hiding some fields by default and adding toggles, or make their default value be the same as the first fields, but I believe this is generally a complex design question. All in all, I would say multiple time zones selector are a possibility, but one that needs to be evaluated thoroughly.

A pinch of formalism

The previous section explains what conversions we need in practice. More abstractly, we can define two conversions that are relevant to us and analyze them for all possible inputs. In both conversions, one of the inputs is the original time zone, and another input is the final time zone representation (and not time zone!) that we want to obtain. The result of the conversion is a time zone, in the final representation, that corresponds to the initial time zone. The two conversions are:

• Uniform conversion: time zone X can be uniformly converted to the representation A, yielding a new time zone Y, if the local time is the same in X and Y in every [8] instant.
• Pointwise conversion: time zone X can be converted pointwise to the representation A if, for every instant T, there exists a time zone Y_T in A so that the local time is the same in X and Y_T at instant T.

I believe this could be formalised even more with math functions, but it really does not matter here [9]. Instead, I would like to give you a couple of examples:

• Let's say I have a wall clock set on the CEST time zone, and you have a wall clock set on the +02:00 time zone. Our clocks always read the same time: for instance, when mine says it's 14:00:00, yours also says it's 14:00:00 (of the same day). Thus, CEST can be uniformly converted to a UTC offset, and the result of this conversion is +02:00.
• Now let's say I have a wall clock set on the Europe/Rome time zone, and you still have a wall clock set on +02:00. Our clocks will read the same time in some periods of the year, but not others. Thus, Europe/Rome cannot be uniformly converted to a UTC offset, because our clocks do not agree in every instant (but they do sometimes). However, it can be converted pointwise, and the result of this conversion can be +01:00 or +02:00 depending on the instant for which it is done. [10]

Now, a few remarks about these definitions:

• First and foremost: there might be much better ways to define these concepts; alternative definitions that are easier to understand, more accurate, etc. However, after 4 failed attempts, yours truly concluded that something is better than nothing and he was sufficiently happy with this version because the definitions (and following conclusions) should at least be correct. However, I'd definitely be happy to hear alternatives!
• To clarify, the main difference between uniform and pointwise conversion is that the result of the uniform conversion must be valid in every instant, whereas the pointwise conversion can have different results in different instants.
• The key feature of these conversions is that the local time is invariant for both. Conversions that can change the local time are not relevant here. The database -> user conversion is one of them.
• It follows from the definitions that whenever uniform conversion is possible, pointwise conversion is also possible, whereas the converse is not true. Intuitively, if two things are the same in every instant (uniform), they will also be the same in whatever specific instant you choose (pointwise). OTOH, if two things are the same in a specific instant, there's no guarantee that they are the same in every instant.

And finally: in practice, we are converting time zones, which is what the definitions above entail. However, we will not look at these conversions only for a limited number of input time zones; instead, we will evaluate the conversions for all possible input time zones in a given representation. The definitions above can easily be extended to the conversion of time zone representations:

• The time zone representation A can be converted uniformly [resp. pointwise] to time zone representation B iff every time zone in A can be converted uniformly [resp. pointwise] to representation B.

Possibility and ambiguity

Soon we will analyze the two conversions in detail for each time zone representation. We will do that looking for two important characteristics: possibility and ambiguity. For each conversion and for each set of inputs, we will ask ourselves:

• Is the conversion possible? That is, is there at least one final value that satisfies the definition?
• If the conversion is possible, is it also unambiguous? That is, is there one and only one final value that satisfies the definition?

As an example, in the previous section we saw that CEST can be uniformly converted to the UTC offset +02:00, so the conversion is possible; it is also unambiguous, because there is no other offset that CEST can be converted to. OTOH, +02:00 can also be uniformly converted to an abbreviation, but this conversion is ambiguous: the result can be CEST, but also EET, IST, and 6 others.

Once again, these definitions are valid for the conversion of a single time zone, but they can be extended to the conversion of an entire time zone representation:

• The conversion from time zone representation A to representation B is possible iff every time zone in A can be converted to B.
• The conversion from time zone representation A to representation B is unambiguous iff every time zone in A can be unambiguously converted to B.

Given our use cases, we can only implement a conversion if it is both possible and unambiguous; else, we can't use it in the application (and not for technical reasons, but because the results would be incorrect).

An analogy

Before examining these conversions in more detail, I think it's worth drawing an (imperfect) analogy with physics.

First, you can think of time zone representations as different systems of measurement of the same physical quantity. Within a given time zone representation, you can think of time zones as multiples of the base unit of that system. And finally, a local time with its time zone can be thought of as a number together with its unit of measurement. For instance, considering length as the physical quantity, two possible systems of measurement are the SI and the imperial system. Some units in those systems are meters, kilometers, feet, miles, etc. Note that this is meant to be an analogy for the inputs only. Chances are you've had to convert from one system to the other at least once in your life [11]; however, that conversion is not similar to the ones we're considering. In fact, it's the same as the database -> user preference conversion that we chose to ignore. And likewise, it is always possible.

Finding an example of uniform conversion is not easy: according to the definition above, we would need to find two units of measurement, in different systems of measurement, such that whatever real-world entity you measure, the measurements will be the same in both units. Two such units I found are the square meter (m²) and the centiare (ca). If you take any entity, measure it in square meters and then in centiares, you will find that the two numbers are identical. Since this remains true for every entity, you can uniformly convert square meters to centiares.

And finally, I'm sorry but I couldn't think of an example for pointwise conversion.

Conversions, in detail

The time has come to examine the conversion in more detail. Below I will analyze each of them for every possible initial and final format. In some cases, I will also include a snippet of PHP code that implements the conversion; you can ignore those bits if you don't care about code. If, instead, you do care about code, we're going to assume that $tz is a DateTimeZone object in the given format, and $time is a string representing the time that we'll use in pointwise conversions.

Uniform conversion

Geographical <-> offset

• In general, geographical zones cannot be uniformly converted to offsets. A simple example would be a geographical zone that observes DST, like Europe/Rome. The offset of the zone changes every few months between +01:00 and +02:00, so no conversion is valid "forever".
• Uniform conversion of offsets to geographical zones is also not possible in general, for the same reason. Additionally, even for the offsets where it is possible, it would be highly ambiguous, because a given offset may correspond to many geographical zones.

Geographical <-> abbreviation

• In general, geographical zones cannot be uniformly converted to abbreviations. Like for the geographical -> offset case, DST is in the way. For instance, the abbreviation for Europe/Rome periodically changes between CET and CEST, and no conversion is always valid.
• Uniform conversion of abbreviations to geographical zones is also not possible for the same reason. And like above, it's (almost?) always ambiguous even when possible.
  • Note that PHP's timezone_name_from_abbr is unreliable: as the manual notes, the function only makes a guess. It accepts some parameters to let you improve that guess, but we don't have enough information to provide them, and even if we did, the conversion would still be ambiguous.

Abbreviation <-> offset

• Uniform conversion of abbreviations to offset is more interesting, because it's almost possible and unambiguous. In fact, we may assume that each abbreviation corresponds to one and only one offset—except this isn't true, because of course it isn't! According to the list, there are three abbreviations that can correspond to multiple UTC offsets. The actual number may vary, especially since we're interested only in the abbreviations accepted by PHP. At any rate, it's probably going to be a small number. Thus, we could make our application reject those "ambiguous" abbreviations and pretend they don't exist. Is this a good idea? That's a question for you, dear reader; as long as we only reject "special" abbreviations, I think it'd be fine, but you tell me. Anyway, if we do that, this conversion would truly become possible and unambiguous. For instance, CEST can be uniformly converted to +02:00; this is always valid, and no other offset corresponds to the CEST abbreviation.
  • Technical note: in PHP, this could be implemented as $tz->getOffset( new DateTime() ), where the DateTime can be anything, and should not affect the result. Due to a PHP bug, this won't actually work well in the PHP version we're using. However, it can be worked around by using ( new DateTime( '2022-10-20 18:00:00 ' . $tz->getName() ) )->format( 'P' ), where the literal date is chosen at random, since it shouldn't make any difference.
• Uniform conversion of offsets to abbreviations is always possible, as long as we forget about the very few ambiguous abbreviations as explained above. However, as anticipated in a previous example, the conversion remains ambiguous: +02:00 can be uniformly converted to CEST, EET, IST, and 6 others.

Visualization

Here's a diagram that shows uniform conversion between representation. Red means impossible, orange means possible but ambiguous, and green means possible and unambiguous. Impossible and ambiguous use different colors for completeness, but we can really only implement the green one.

Pointwise conversion

Geographical <-> offset

• Geographical zones can be converted to offsets pointwise. For instance, above I said that Europe/Rome cannot be uniformly converted to an offset because the result could be +01:00 or +02:00 depending on the time. But since pointwise conversion only needs to be valid for a given instant, it is definitely possible. Furthermore, this conversion is also unambiguous.
  • In code: $tz->getOffset( new DateTime( $time ) )
• Offsets can be converted pointwise to geographical zones, but this conversion is still ambiguous. For instance, let's say we're converting +02:00 to geographical for 2022-10-19 15:00:00. Aside from Europe/Rome, there are roughly 75 valid results.

Geographical <-> abbreviation

• Converting geographical zones to abbreviations pointwise is not (always) possible [12]. This table has many examples of geographical zones without a corresponding abbreviation. Moreover, PHP agrees that this is the case [13].
  • In code, this would be: ( new DateTime( $time, $tz ) )->format( 'T' ), but it can return an offset instead of an abbreviation.
• Apparently, abbreviations can be converted pointwise to geographical zones. I say "apparently" because that's what some quick experiments would suggest, but I couldn't find a reliable source about it; additionally, PHP recognizes some abbreviations that do not correspond to any geographical zone, but these all seem to be special cases (like the military zones). At any rate, even if we assume that the conversion is possible (e.g., by having a list of allowed abbreviations), it's definitely ambiguous: for instance, according to this table (sort by "DST" under "time zone abbreviation"), CEST could be converted to 48 different geographical zones [14].

Abbreviation <-> offset

• Abbreviations can be uniformly converted to offsets without ambiguities, so pointwise conversion is possible and unambiguous a fortiori. However, like above, we may have to exclude some special abbreviations.
  • The code for this is the same I wrote for uniform conversion, except that here we can use a specific time instead of a random one.
• Offsets can be uniformly converted to abbreviations, so pointwise conversion is possible a fortiori. However, it remains ambiguous even when limited to a single point in time, for the same reason explained above.

Visualization

Here's a diagram to visualize the pointwise conversions, with the same legend as above:

Monte Carlo conversions?

In the previous sections there's actually a hidden assumption [15]: that time zone rules don't change. This assumption was first implied when defining what it means for two time zones to represent the same local time in "every" instant. You may argue that time zone rules do change; of course they do! I wrote more about it in T314871. If time zone rules change, the results of the conversions above may change, and perhaps even their (im)possibility. In fact, the conversion rules mentioned above are guaranteed to be valid only for dates in the past. As an example, if I had to convert Europe/Rome to a UTC offset pointwise for October 11, 2025, I would say that the result is likely to be +2, but Italy could stop observing DST before 2025, in which case the result would become +1.

It would be entirely correct to say that converting time zones for dates in the future is tantamount to guessing. But don't panic! On the bright side, this guess has good chances of being correct. And on the even brighter side, we don't have to worry about it. We already have some code in place to address time zone rules changes, see T314871 and T316687. That should be sufficient.

Oh, and by the way, there's another assumption, but this one is not hidden: as I told you in the very first section, we're assuming that time zone abbreviations are always disambiguated. This does not affect the theory behind the conversions, but it may affect the practice. And not just because of UX clutter: abbreviations also need to be disambiguated when we ask PHP to convert them. This should be doable, although I haven't fully investigated that. I will take a closer look if necessary.

Not all those who wander are lost...

...and I wholeheartedly hope you aren't—even though we definitely wandered a lot! Now that we know everything we needed to know about conversions, we could start drawing conclusions, so should we? By now, you should really know that the answer is "it depends"; in this case, it depends on the definition of "we". I will tell you how the concepts above can be used to draw conclusions, and give some examples. Then, you will play with these concepts and draw conclusions for yourself. This is motivated by a simple fact: we have 3 formats and 6 places where we need to convert them. Listing all the possibilities would be a nightmare, because there are many, and some of them may not be of practical interest. Thus, you can analyze only the ones you think are worth analyzing.

The technique that I'd like to use here (and invite you to do the same) is some sort of combined backwards + forwards analysis. The core idea is that you decide what representation you would like to have in a certain step, and then walk the graph of conversions inside the application backwards to work out what formats would be possible in the previous steps, which is something you can infer from the conversion graphs above. Then you walk the remaining arrows forwards, until you have covered all steps. This may sound confusing, but it's actually simpler than it sounds, so here are a couple of examples:

• Ex. 1: you decide that the database should only store geographical zones. From the application graph, you see that the database has two incoming edges, one from the API and one from the form. Since these are both uniform conversions, you now look at the diagram for uniform conversion. No format can be uniformly converted to geographical, so both the API and the form should allow entering only geographical time zones. The backwards analysis ends here because there are no other edges to walk backwards. Now you can start again from the DB node for the forwards analysis. Let's consider the edge pointing to the script: this is a pointwise conversion whose final format must be geographical. Since the database can already only store geographical zones, there are no issues here. And finally, we have the pointwise conversion for the interface. If we look at the pointwise conversion graph, we see that geographical zones can only be converted to offsets. Thus, in the interface we could only show geographical zones and offsets.
• Ex. 2: you decide that the database should only store abbreviations. No other format can be converted uniformly to an abbreviation, so both the API and the interface should only accept abbreviations. The pointwise conversion to geographical for the script would not be possible, and we wouldn't be able to update the data for any event. And finally, in the interface we could use either offsets or abbreviations.

Of course, your initial assumption might be more complex. For instance, you may decide that a certain step could accept more than one format. And you also don't have to start from the database: you can start from any step you want. You can even decide what the formats should be in multiple places, and work out the remaining ones. It goes without saying that the more you restrict it, the higher the chance of a certain combination not being possible because it requires an impossible conversion.

As I said, exploring more possibilities is left as an exercise for the reader, because there are many things that can be tried, and this comment is already long enough without listing them all. But worry not, I'm not going anywhere, and I'd happily help you in this exploration if you want. Other possible combinations can be examined here on phab, or in a call if you prefer. Don't be afraid to ask: together we stand, divided we fall.

Conclusions

This dissertation is intentionally open-ended. As already anticipated, it does not include any recommendations: its goal was to explain, not recommend. Ideally, the next step would be a group conversation about the status quo, the options we have, and what it takes to implement them. We could go through the most promising options one by one, see if they're possible, and eventually choose one.

More importantly, I firmly believe that what I wrote here may also be useful when dealing with timezone-related features. Not only within the scope of this task, but in the whole application, in both the frontend and the backend. If I achieved my goal of documenting all the time zone formats, their limitations and strengths, and how they interact with each other, then this dissertation could help us validate the assumptions and decisions we made, are making, and will made in the realm of time and time zones.

In fact, the main goal here was to collect some knowledge and share it with you. I learned (and realized) many things along the way, and hopefully you did, too. The research I did, and the time spent summarizing them, gave me more confidence in answering (future) time zone questions; and now I hope that you too will be more confident. This is perhaps what, above all else, gave me the force to write this long comment.

Post scriptum

I know that this comment has been difficult for you to read, and I apologize. If it helps make you feel better, it was also very hard for me to write. Someone once said that «He who fights with monsters should see to it that he himself does not become a monster»; now I'm afraid I may become a time zone.

You may find errors (from innocent inaccuracies to plain blunders), oversimplifications, or overcomplications of simple concepts that you already understood much better than me; I may have forgotten to say some things that I wanted to say. Please don't take this dissertation as gospel, and please, please complain if something looks wrong or incomplete. The topic is complex, but I sincerely hope that something I wrote here will make sense to you. Even if it's just a sentence in a labyrinth of letters; O Time thy pyramids.

[1] - See for instance this answer on Stack Overflow about the lack of standardization, and for more examples of ambiguity.
[2] - You can read a bit more about computers here, where it also explains the POSIX format and the zdump command.
[3] - https://www.ietf.org/timezones/tzdb-2018g/theory.html#naming
[4] - See introductory paragraph of https://en.wikipedia.org/wiki/List_of_UTC_offsets
[5] - See introductory paragraph of https://en.wikipedia.org/wiki/UTC_offset
[6] - You can read about it at https://en.wikipedia.org/wiki/Summer_time_in_Europe or https://www.timeanddate.com/time/europe/eu-dst.html
[7] - I'm saying "participant" just because that's what Ilana's comment says. But then there would also be the question of what an organizer sees if they view the event; do they see the event time zone (and so we make a special case for organizers), or their own time zone (in which case we should say "user" instead of "participant")?
[8] - Here, you may be wondering what "every" means. Since it appears in a definition, there's no right answer. In practice, we would really only need the local times to be the same between the event start and end time, but that doesn't help us formulate a good definition of "every". For simplicity, you can define it as: from January 1st, 2022, to December 31st, 2026. This is just an example though, and not the actual definition.
[9] - For instance, pointwise conversion may perhaps be interpreted as a restriction of uniform conversion. Speaking about maths, I hope you'll forgive me if I happen to write "convergence" or "continuity" instead of "conversion" without noticing. Naming things is hard, and I had to borrow those names from something else.
[10] - If you know something about relativity, the expression "our clocks agree" may send shivers down your spine, because you know we may not be able to read our clocks in the same instant. Luckily, we can ignore relativistic effects for now; this dissertation is already complex enough without adding relativity to the mix.
[11] - Unrelated: I swear I didn't choose this example on purpose. However, now that it's here, I feel the urge to mention a nice trivia: you can convert between miles and kilometers using Fibonacci numbers. Amazing, right?
[12] - Interestingly, the IANA database seems to contain a mapping from geographical zones to abbreviations, as explained in this answer on Stack Overflow. Whether that data is accessible from PHP, I'm not sure. But again, it looks like the conversion is not possible in many cases.
[13] - For a list of geographical zones without a corresponding abbreviation in PHP, see P35450. That is 171 out of 425 time zones known to PHP. Honestly, I'm not quite sure why some geographical zones are in this list. For instance, Brazil and Argentina seem to use time zone abbreviations according to Wikipedia. I have no idea if it's just PHP not recognizing those abbreviations, or if this has to do with DST, or something else. At any rate, if PHP says "no", it really means "no".
[14] - The CLDR mapping for Windows time zones has a similar table, and many ambiguities stand out.
[15] - Or maybe more than one, at this point I don't really know. Assumptions are the only thing that could deliver us from the evil of time zones.

@Daimona, wow! This is an epic Phabricator comment, and it was a fun and fascinating dive into the depths of timezone complexities. Thank you so much for taking the time to write it down and to break down your thought process in such detail. Below, I'll share some thoughts that came to mind while reading this as well as what makes sense for next steps. FYI, I read some sections more thoroughly than others, so there may be some things that I miss in my comment below (and, if that is the case, I'm happy to discuss this more during our 1:1 tomorrow). Anyway, here are some preliminary comments that can maybe help us move forward:

• For V1, we want to focus on implementing a solution that is:
  • Not too technically complex
  • Generally intuitive to both Wikimedians and newcomers
• My original instinct was that the time zone abbreviation (such as EST) format was preferable, since it seemed generally understandable and common, plus it was short. However, from reading your explanation and looking into the time zone abbreviation explanation on enwiki ("these are not part of the international time and date standard ISO 8601 and their use as sole designator for a time zone is discouraged... their ambiguity explains their deprecation in the internet era, when communications more often cannot rely on implicit geographic context to supply part of the meaning"), I understand their limitations and perhaps why the timezone selector in wiki Preferences does not rely on this format. Plus, it's an important to highlight that one abbreviation can be used by multiple timezones. We have events in the movement that are regional and/or global, so we need to avoid creating confusion over which timezone we are referring to specifically. For these reasons, I'm okay with not relying on the abbreviation time zone format for now.
• For V1 and perhaps beyond, I'm fine with allowing organizers to select option 1 (geographic timezone) or option 2 (UTC offset), which is how I believe we have currently implemented time zone support. This is both what we currently have available on the wikis now and in compliance with what I understand to be current internet standards. I still do have some concerns with the fact that the location identifier may confuse people who are not in the given location (such as the NYC vs. Philadelphia example), but:
  • This would raise a larger question of what we currently display in the timezone selector in other parts of the wiki UI (such as the timezone selector in Preferences)
  • This is something we could look into improving or changing later on, if people are indeed confused by the representation (but we should test on real users before rushing to conclusions)
  • There is also the option for the UTC offset for organizers and/or participants
• Multiple timezone selectors (i.e., one for the start date and one for the end date) aren't a feature we have heard from organizers yet, and they add a lot of extra complexity. While it is good to know that we could explore it in the future, I can't think of a use case of when this would be needed and it's not something we need to accommodate in the user experience, I think.

So, in summary: No need to accommodate abbreviations for V1, and we can focus on supporting the geographic and timezone offsets (based on the organizer selection, wiki default, and participant preference), which I believe we already support in our implementation.

Let me know what you think/if this sounds good!

In T316688#8340224, @ifried wrote:

@Daimona, wow! This is an epic Phabricator comment, and it was a fun and fascinating dive into the depths of timezone complexities. Thank you so much for taking the time to write it down and to break down your thought process in such detail.

Thank you for taking the time to go through this stream of consciousness (kind of).

• For V1, we want to focus on implementing a solution that is:
  • Not too technically complex
  • Generally intuitive to both Wikimedians and newcomers

I think it makes sense. Technically, these options all have roughly the same complexity; and I'm most probably not the best person to say what's more intuitive.

• My original instinct was that the time zone abbreviation (such as EST) format was preferable, since it seemed generally understandable and common, plus it was short.

It definitely is. Familiarity and simplicity only count as one pro each, but these really are strong pros.

• For V1 and perhaps beyond, I'm fine with allowing organizers to select option 1 (geographic timezone) or option 2 (UTC offset), which is how I believe we have currently implemented time zone support.

Yup, confirming that this is the current implementation of the time zone selector (both in the CampaignEvents extension, and in Special:Preferences).

• Multiple timezone selectors (i.e., one for the start date and one for the end date) aren't a feature we have heard from organizers yet, and they add a lot of extra complexity. While it is good to know that we could explore it in the future, I can't think of a use case of when this would be needed and it's not something we need to accommodate in the user experience, I think.

The problem is, in some scenarios it wouldn't be a feature, but rather a necessity. Using the same time zone for all dates has two main drawbacks:

• If we allow abbreviations, we need to account for events whose abbreviated time zone changes while the event is ongoing (if it's a multi-day event that happens at the same time as a DST switch).
• Some conversions in the application would have to be uniform, i.e., valid for all dates. If every date had its time zone, then all conversions would be pointwise (in practice, this means we can convert geographical to offset).

So, in summary: No need to accommodate abbreviations for V1, and we can focus on supporting the geographic and timezone offsets (based on the organizer selection, wiki default, and participant preference), which I believe we already support in our implementation.

I believe this is the status quo, so it's certainly doable.

Hello, would it be possible if there is a timezone change to have a warning "⚠️ Be aware a timezone change is expected during event." or something like that?

In T316688#8340952, @CKMIE89 wrote:

Hello, would it be possible if there is a timezone change to have a warning "⚠️ Be aware a timezone change is expected during event." or something like that?

Staying true to what I wrote above: it depends. For what kind of time zone changes would this be used, and what problem could it solve? Technically speaking, it should be possible to implement, at least in some cases.

@Daan.L and @gonyeahialam:

We have made a final decision for the following:

• Events can be displayed as a geographic timezone (such as "Americas / New York") or as a UTC offset.
• We will only display one timezone (rather than two)
• For in person events, the timezone set by the organizer will be displayed
• For online and hybrid events:
  • if the user is not logged in: wiki default timezone will be displayed
  • if the user is logged in: timezone set in user preferences will be displayed

We have an earlier exploration of how the time and timezone can be displayed on the event page, as per https://phabricator.wikimedia.org/T316688#8253066. However, it doesn't incorporate the latest updates including:

• The fact that we should display the event in only 1 timezone (not 2)
• We may want to have a separate section/area for timezone rather than in the same section/area as the date and time, since users may mistake the timezone as being the event location. Do you agree? If yes, can you update the prototypes with a separate timezone section? If no, can you share why and what you think is the best course of action?

Thanks!

Timezone design (View Design Specs)

Event details modal	Event details tab

Noting that the event time is shown in the following places:

• "More details" dialog
• Special:EventDetails
• Registration header on event page
• Special:MyEvents (start date only)

The first two are covered by the wireframes we already have, but what about the other two?

@gonyeahialam Hello! See the comment above from Daimona. We will need wireframes for how the time zone will look on:

• Registration header on event page
• Special:MyEvents (start date only)

In T316688#8353320, @Daimona wrote:

Noting that the event time is shown in the following places:

• "More details" dialog
• Special:EventDetails
• Registration header on event page
• Special:MyEvents (start date only)

The first two are covered by the wireframes we already have, but what about the other two?

For Special:MyEvents (start date only), we only show the date so there will be no need to show a timezone.

Registration header on the event page
Due to space constraints, it is best if the timezone is together with the date&time. Users can see the full info when they open more details.

In T316688#8353486, @gonyeahialam wrote:

For Special:MyEvents (start date only), we only show the date so there will be no need to show a timezone.

Why? It's certainly not as useful as when we're also showing the time, but the date is affected by the time zone just like the time is.

Registration header on the event page
Due to space constraints, it is best if the timezone is together with the date&time. Users can see the full info when they open more details.

Could this reintroduce some of the concerns we had regarding i18n and users potentially mistaking the time zone for the location? Especially if the location itself is not shown in the header. What do you think about not showing the time zone in the header?

Hmmm, I'm actually concerned about showing the time zone in the same line as the date/time in the registration header. If someone only saw the registration header and did not click "More details,' they could easily think that the event location is in Lagos, even if it is not. I think it is really important to provide some indicator of the time zone in this case.

Registration Header
Having it on one line would be great in terms of appearance but we could separate the timezone in the registration header.

Thanks for making this update, @gonyeahialam! I think this is much more clear to the user, and clarity is the #1 priority for this part of the experience. When you get a chance, I would like to know your response to the question Daimona shared above regarding why we shouldn't display the time zone in MyEvents, but it's not pressing or urgent (in other words, please feel free to respond when you're back at work next week, as I know it is late for you now!). I don't think it is a hard requirement to update MyEvents to show time zone for V1.

In T316688#8353496, @Daimona wrote:

In T316688#8353486, @gonyeahialam wrote:

For Special:MyEvents (start date only), we only show the date so there will be no need to show a timezone.

Why? It's certainly not as useful as when we're also showing the time, but the date is affected by the time zone just like the time is.

Sorry, I didn't take into consideration that the timezone affected the date also.

Since this page is for event organizers, they would likely not be mistaking the timezone for location. I suggest we combine it if possible.

@gonyeahialam Thank you for the response! I agree that the risk of time zone confusion for the MyEvents view is considerably lower for organizers, since they created the events themselves and selected the time zone. For this reason, I also think it's fine to include the time zone in the same line for MyEvents, if we add a column for event time. However, I don't think it is essential to add time to MyEvents for V1 so I have added it as a potential task (for a later date) into our backlog: T322069

In T316688#8357844, @gonyeahialam wrote:

Since this page is for event organizers, they would likely not be mistaking the timezone for location. I suggest we combine it if possible.

In T316688#8357979, @ifried wrote:

I agree that the risk of time zone confusion for the MyEvents view is considerably lower for organizers, since they created the events themselves and selected the time zone.

Oh, right, for some reason I failed to consider this when I wrote the previous comment.

However, I don't think it is essential to add time to MyEvents for V1 so I have added it as a potential task (for a later date) into our backlog: T322069

Sounds good to me, no need to rush and we can think of what would make the most sense later.

Great, thanks! In that case, we can consider open questions in this ticket resolved, and the team can focus on the related subtasks: T322050, T321717, and T321718.