Change 216909 abandoned by Anomie:
Date and time picker widget

Reason:
Since OOJS-UI isn't currently in a position to accept this, Ia3942c76804c865c1039904d170ee6eafcdc6793.

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

Sooo... we now have the two in MediaWiki core.

• DateTimeInputWidget by @Anomie: 57342159dab992bcd28d1e8fc4c1ca804bf61962
• DateInputWidget by @matmarex: 76b630185496ef7c8e29efd4b5d99f756bfaaea7

Unfortunately they have almost no common code :/

Wondering who should weigh in on this to move this forward?

In T91148#1930378, @violetto wrote:

Wondering who should weigh in on this to move this forward?

Not sure about "who", but I can look at what needs to be weighed in on.

Regarding two similar-but-different widgets, someone would have to analyze the differences between the two and decide which approaches to use. Then someone would have to write code to implement the decisions in one widget. Off the top of my head,

• DateInputWidget doesn't handle times, while DateTimeInputWidget does. Time input is required for T92893.
• DateInputWidget takes input as a single textbox, changes the format displayed when focused/unfocused, and only accepts input in YYYY-MM-DD style. DateTimeInputWidget takes input as individual date components and does not change format when focused.
• DateInputWidget uses its own i18n mechanism (from moment.js), while DateTimeInputWidget uses MediaWiki's standard i18n.
• DateInputWidget looks like it can only handle the Gregorian calendar. DateTimeInputWidget is designed to easily support other calendars if someone writes the code for converting a JavaScript Date into that calendar's components.
• DateInputWidget's calendar has the cool "up arrow" feature, and supports selecting a year+month with no day more sensibly.

Regarding the fact that neither of these are in oojs-ui,

• T113681: Split oojs-ui module into smaller ones needs to be resolved.
• Someone needs to decide about i18n: Use the standard oojs-ui mechanism backed by translatewiki, somehow integrate cldrjs, or integrate moment.js and use its i18n.

Thanks @Anomie, I was going to write pretty much the same thing. We need an experienced frontend developer to make decisions on the parts that Anomie and I disagree on, and preferably also implement them (although I guess one of us could do it in the end). Both versions implement a very similar design, close to M53, with some small differences (primarily the input field behavior). I'm not sure who we could escalate this to :/

From the library users' perspective, the issue is pretty much resolved, and both DateTimeInputWidget and DateInputWidget (with the differences described by Anomie) are available to be used. The public interface shouldn't change (I think at the very least, you can rely on #getValue/#setValue methods continuing to behave in the same way they do now).

Design feedback wouldn't hurt (never does ;) ), but I think we're fairly solid here, and at the moment any changes would have to be implemented in both versions (which would be a pain). Gotta set up a demo/comparison of the two again…

integrate moment.js and use its i18n

That would be blocked on their adopting a standard shared with MediaWiki core, see https://www.mediawiki.org/wiki/Globalize .

Got it. It will be good to frame the use cases around date and time input widget to make sure we're making some informed decisions, otherwise it'll be hard to decide what should stay and what shouldn't based on your implementations. I don't mind doing this.

The English Wikipedia community is complaining about having to use 2 different date selection widgets and agrees that we should consolidate on one.

FWIW, I think the DateInputWidget is better for just choosing dates (mainly due to T170607). How hard would it be to add an optional time input interface to it?

After revisiting the two widgets in several contexts, I think the DateTimeInputWidget is only usefully crafted for one special use case, APISandbox. It fulfills the needs there, but is generally too complex on a user experience and component level.
It seems more performant, less complex and also general better approach to have two different components, a DateInputWidget and a TimeInputWidget for those two tasks. No other web framework is providing a combination for the complexity of mixed inputs, Boostrap has none, Material Design only Date picker.

The only implementations are by developers on top of other libraries, that show the unnecessary complexity of those time pickers:

• https://malot.fr/bootstrap-datetimepicker/
• https://plugins.jquery.com/datetimepicker/ https://xdsoft.net/jqplugins/datetimepicker/

This goes alongside the most recent comments above.