Page MenuHomePhabricator

Make the time inputs work with non-UTC timezones on Special:(Enable|Edit)EventRegistration
Closed, ResolvedPublic2 Estimated Story Points

Description

Acceptance Criteria:

  • Hide the timezone indication from the field ("Z")
  • Make sure that "min" and "max" continue working if the timezone changes
  • When first clicking on an empty datetime input, it should set the current time in the specified timezone, and not UTC

Event Timeline

ifried set the point value for this task to 2.
Daimona removed the point value for this task.
Daimona renamed this task from Ensure that date/time input widget functions with non-UTC timezones to Make the timezone used by DateTimeInputWidget customizable.Aug 19 2022, 5:42 PM

I just actually read the code of DateTimeInputField and related classes (in JS) -- admittedly my first in-depth look at that code. DateTimeInputWidget itself doesn't really do much with dates themselves; the actual formatting logic is in DateTimeFormatter and its subclass used by default, ProlepticGregorianDateTimeFormatter. That code deals with time zones a bit, but it only has 2 modes: UTC and local. The whole class relies on the fact that these are the only possible modes, and is tailored specifically to them (for instance, see the fullZones and shortZones params to the ctr, getLocal() and toggleLocal(), the local event, etc.). All in all, making it accept custom time zones would be possible but hard-ish (especially if we need to go through deprecations etc.). Here I should also mention that the noJS implementation of the widget is <input type="datetime", which was removed from the specs a while ago and replaced by datetime-local; that should be kept in mind when changing the implementation.

Instead, I think we should keep using the existing widget with UTC, and make the necessary adjustments in the extension code. For instance, we can hide the timezone by passing a different date format to the constructor; the widget is autoinfused so we can't do that, but we may be able to change it afterwards. min and max could be updated dynamically when the tz selector changes. It's not as clean as adding proper tz customisation to the existing widget, but I think it's a perfectly reasonable solution, and certainly much easier to implement.

As such, I'm going to repurpose this task once again to only be about our use case, and I've created T315874 for the actual longer-term change to the widget.

Daimona renamed this task from Make the timezone used by DateTimeInputWidget customizable to Make the time inputs work with non-UTC timezones on Special:(Enable|Edit)EventRegistration.Aug 22 2022, 11:48 AM
Daimona updated the task description. (Show Details)

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

[mediawiki/extensions/CampaignEvents@master] Make time inputs work correctly with non-UTC timezones

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

โ€ข vyuen changed the task status from Open to In Progress.Aug 24 2022, 5:44 PM
ldelench_wmf subscribed.

Discussed at sprint planning: this feature is not for darkship

Change 825355 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Make time inputs work correctly with non-UTC timezones

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

vaughnwalters subscribed.

โœ… Hide the timezone indication from the field ("Z")

Screen Shot 2022-10-11 at 6.20.37 PM.png (294ร—920 px, 97 KB)


โœ… Make sure that "min" and "max" continue working if the timezone changes

an example of min value working correctly for enabling an event:

  • timezone is UTC and start date/time is set one hour in the future
  • then a 4 hour offset is added
  • and the event will correctly not allow registration

set time in the future and then add offset and it correctly doesn't allow you to set the date in the past.gif (1ร—3 px, 1 MB)

  • then time zone is reset to UTC (using the same date/time input as the above example), and registration is enabled:

but then can change offset and it allows registration.gif (1ร—3 px, 1 MB)


โœ… When first clicking on an empty datetime input, it should set the current time in the specified timezone, and not UTC

Screen Recording 2022-10-11 at 6.21.34 PM.gif (1ร—3 px, 3 MB)

I have conducted some basic tests on the timezone selector in the beta cluster, and it looks good to me. I'm marking this as Done.

Screen Shot 2022-10-12 at 4.46.57 PM.png (1ร—1 px, 131 KB)