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

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

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!

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

In T315691#8309637, @vaughnwalters wrote:

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:

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

✅ 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
event page:

Special:EventDetails

✅ 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

✅ Cannot register for an event after it has finished

✅ "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.

There should be some padding between these elements at smaller breakpoints

In T315691#8313333, @vaughnwalters wrote:

@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.

In T315691#8314088, @Daimona wrote:

In T315691#8313333, @vaughnwalters wrote:

@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.