Page MenuHomePhabricator

Add timezone selector to the edit registration form
Closed, ResolvedPublic

Description

Acceptance Criteria:

  • Organizers can specify the timezone of the event on Special:CreateEventRegistration and Special:EditEventRegistration

Testing notes

Aside from making sure that the form field itself is functional (i.e., accepts valid input and rejects invalid input with an error message), changing the timezone of an event has deep implications and everything related to time should be tested to make sure that it respects the specified timezone. Some things to test (potentially incomplete, from T311126#8226101):

  • Enable/edit registration: time inputs should be functional and for existing events, the timezone should be retained
    • Cannot enable registration with start date in the past
    • End date must be after start date
  • View event time on event page and Special:EventDetails
  • View start times on Special:MyEvents, make sure that sorting is correct even if events are on different timezones
  • Cannot register for an event after it has finished
  • "Get details of an event" returns correct info

Note: There might be some usability issues with the time input fields are used and the timezone is not UTC. If those issues are preventing you from testing a given scenario, try again once T309631 is resolved.

Event Timeline

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

[mediawiki/extensions/CampaignEvents@master] Add timezone selector to Special:(Enable|Edit)EventRegistration

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

vyuen changed the task status from Open to In Progress.Aug 24 2022, 5:42 PM
vyuen moved this task from Backlog to Darkship on the Campaign-Registration board.

Change 825340 merged by Cmelo:

[mediawiki/extensions/CampaignEvents@master] Add timezone selector to Special:(Enable|Edit)EventRegistration

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

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

[mediawiki/extensions/CampaignEvents@master] Add timezone selector to Special:(Enable|Edit)EventRegistration

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

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

[mediawiki/extensions/CampaignEvents@master] Harmonize format of start and end timestamp

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

Change 828649 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Harmonize format of start and end timestamp

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

Daimona updated the task description. (Show Details)
Daimona updated the task description. (Show Details)

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

[mediawiki/extensions/CampaignEvents@master] Make the timezone a parameter to EventFactory::newEvent

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

Change 835614 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Make the timezone a parameter to EventFactory::newEvent

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

Change 826343 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Add timezone selector to Special:(Enable|Edit)EventRegistration

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

@ifried @Daimona - I believe we should be showing

  1. online events in participant timezone and
  2. in person events in the organizer-specified timezone

is this correct?

If so, you can see in the gif below that the event displays in the participant (right panel) timezone, regardless of whether it is an online or in person event. If my understand of how this should work is incorrect, ignore this comment!

Screen Recording 2022-10-11 at 2.45.46 PM.gif (1×3 px, 3 MB)

@vaughnwalters: Yes. Online events should be in participant timezone. In person events should be in the organizer-specified timezone.

If so, you can see in the gif below that the event displays in the participant (right panel) timezone, regardless of whether it is an online or in person event. If my understand of how this should work is incorrect, ignore this comment!

No, your understanding is perfect! It's just that we haven't implemented it yet, because it's covered by another task: T316688

✅ Enable/edit registration: time inputs should be functional and for existing events, the timezone should be retained

Enable registration time input functional:

Screen Recording 2022-10-12 at 5.59.23 PM.gif (1×2 px, 1 MB)

Edit registration time input functional, and timezone retained after save:

Screen Recording 2022-10-12 at 6.03.30 PM.gif (1×2 px, 2 MB)

✅ Cannot enable registration with start date in the past

Screen Recording 2022-10-12 at 3.03.30 PM.gif (1×2 px, 812 KB)


✅ End date must be after start date

Screen Shot 2022-10-12 at 3.08.35 PM.png (1×1 px, 626 KB)


✅ View event time on event page and Special:EventDetails
event page:

Screen Shot 2022-10-12 at 3.11.38 PM.png (410×2 px, 267 KB)

Special:EventDetails

Screen Shot 2022-10-12 at 3.12.32 PM.png (732×1 px, 262 KB)


✅ View start times on Special:MyEvents, make sure that sorting is correct even if events are on different timezones

In the below example, three events are set to the same start time (Nov 1 00:00) and end time (Nov 5 00:00), but have various offsets.
Event:T315691a offset: -12:00
Event:T315691b offset: +14:00
Event:T315691c offset: 00:00

The sorting by date is working correctly with offsets. Once online events show participant timezone and in person events in the organizer-specified timezone, this will need to be tested again though. Testing here with user organizer Testbeta

Screen Recording 2022-10-13 at 12.47.34 AM.gif (1×2 px, 645 KB)


✅ Cannot register for an event after it has finished

Screen Shot 2022-10-12 at 5.02.42 PM.png (1×2 px, 769 KB)


✅ "Get details of an event" returns correct info

GET request at https://en.wikipedia.beta.wmflabs.org/w/rest.php/campaignevents/v0/event_registration/171

{
    "id": 171,
    "name": "T315691",
    "event_page": "Event:T315691",
    "event_page_wiki": "enwiki",
    "chat_url": null,
    "status": "open",
    "timezone": "America/Chicago",
    "start_time": "20221019200344",
    "end_time": "20221026200828",
    "online_meeting": true,
    "inperson_meeting": false,
    "meeting_url": null,
    "meeting_country": null,
    "meeting_address": null
}


@Daimona a couple small UI notes:
Should we clean up these error messages now so the errors also do not have seconds or the Z in them? example from the below screencap: 2022-10-12T20:03:40Z. Low priority, but would be cleaner.

Screen Shot 2022-10-12 at 4.11.15 PM.png (188×1 px, 106 KB)

There should be some padding between these elements at smaller breakpoints

Screen Shot 2022-10-12 at 4.12.13 PM.png (332×1 px, 116 KB)

@Daimona a couple small UI notes:
Should we clean up these error messages now so the errors also do not have seconds or the Z in them? example from the below screencap: 2022-10-12T20:03:40Z. Low priority, but would be cleaner.

This is out of our control... The message is used in core's HTMLDateTimeField, and we have no way to change it. We hacked the form field to make it work with time zones other than UTC, but the widget itself does not support other timezones, so it will always format dates in UTC. I guess this might get fixed as part of T315874, but that task is not for us, and I'm not sure if someone will ever want to tackle it...

Also, this error message at least actually uses ISO 8601 for the date, so its meaning might be clearer. The field itself, OTOH, used an ISO 8601 timezone designator inside the input value, which is not formatted according to ISO 8601, and thus potentially more confusing.

There should be some padding between these elements at smaller breakpoints

I agree, but that is the default styling of the generic "select or other" field type, that you can see in other places like Special:Diff. That said, several places that use the field, like Special:Preferences and Special:Block, add their own CSS to separate the two inputs. I've created T320717.

@Daimona a couple small UI notes:
Should we clean up these error messages now so the errors also do not have seconds or the Z in them? example from the below screencap: 2022-10-12T20:03:40Z. Low priority, but would be cleaner.

This is out of our control... The message is used in core's HTMLDateTimeField, and we have no way to change it. We hacked the form field to make it work with time zones other than UTC, but the widget itself does not support other timezones, so it will always format dates in UTC. I guess this might get fixed as part of T315874, but that task is not for us, and I'm not sure if someone will ever want to tackle it...

Also, this error message at least actually uses ISO 8601 for the date, so its meaning might be clearer. The field itself, OTOH, used an ISO 8601 timezone designator inside the input value, which is not formatted according to ISO 8601, and thus potentially more confusing.

There should be some padding between these elements at smaller breakpoints

I agree, but that is the default styling of the generic "select or other" field type, that you can see in other places like Special:Diff. That said, several places that use the field, like Special:Preferences and Special:Block, add their own CSS to separate the two inputs. I've created T320717.

Okay thanks for the explanations @Daimona and creating that task to fix the padding, I'll moving this to design sign off.

The time zone selector now displays when an organizer enables or edits registration (see screenshot example below), so I'm marking this as Done.

Screen Shot 2022-11-10 at 9.33.06 AM.png (412×1 px, 47 KB)