ApiSandbox timestamp fields should allow pasting timestamps
Open, Needs TriagePublic

Description

The date/time selector widget is great for manual entry but when copying a timestamp from somewhere else it is a bit cumbersome. It would be nice if the widget could detect when a proper timestamp is being pasted and properly set the value.

Tgr created this task.Sep 26 2017, 8:08 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 26 2017, 8:08 AM
Anomie added a subscriber: Anomie.

It should probably be supported by the oojs-ui widget rather than being done as a special case by ApiSandbox.

Assuming it's possible (i.e. not stopped by browser filtering on whatever input widgets are in use), it's probably a decent idea. Recognizing different timestamp formats might need some thought.

@Tgr Please define “proper timestamp”.

Note in oojs-ui this is the mw.widgets.datetime.DateTimeInputWidget widget. So not properly oojs-ui, I suppose.

In the context of the API, a "proper timestamp" is any format accepted by the MWTimestamp class, which has some strange idiosyncrasies such as ignoring timezones despite syntactically supporting them. These formats are:

  • ISO 8601 date and time, 2001-01-15T14:56:00Z (punctuation and Z are optional)
  • ISO 8601 date and time with (ignored) fractional seconds, 2001-01-15T14:56:00.00001Z (dashes, colons, and Z are optional)
  • MediaWiki format, 20010115145600
  • Generic numeric format, 2001-01-15 14:56:00 (optional timezone of GMT, +##, or -## is ignored)
  • EXIF format, 2001:01:15 14:56:00
  • RFC 2822 format (timezone may be omitted), Mon, 15 Jan 2001 14:56:00
  • RFC 850 format (timezone may be omitted), Monday, 15-Jan-2001 14:56:00
  • C ctime format, Mon Jan 15 14:56:00 2001
  • Seconds since 1970-01-01T00:00:00Z as a 1 to 13 digit integer (excluding 0)
  • The string now

oojs-ui should almost certainly not bother with seconds since the epoch or the string "now", and might want to honor timezones when those are specified. As long as "2001-01-15T14:56:00Z" and "20010115145600" are supported, that should cover the majority of API use cases. It should probably also accept input matching the widget's current display format.