Implement the Extended Date/Time Format Specification
Open, Needs TriagePublic

Description

We should adopt the "Extended Date/Time Format Specification" (EDTF) profile [1] for ISO 8601, which allows for, for example, uncertain and vague dates, for use in properties with a "Point in time" datatype.

ISO 8601-2019, due in the middle of that year, is expected to support all of the features of EDTF.

Disclosure: I contributed, partly as a Wikimedian, to the draft of this specification.

Assigning to Lydia initially, for delegation as appropriate ;-)

[1] http://www.loc.gov/standards/datetime/edtf.html

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMon, Oct 22, 9:22 PM
Mvolz added a subscriber: Mvolz.Tue, Oct 23, 6:54 AM
Jc3s5h added a subscriber: Jc3s5h.Tue, Oct 23, 3:17 PM

This specification is a non-starter because Wikidata supports both the Gregorian and Julian calendar while this spec only supports the Gregorian calendar.

Mvolz added a comment.EditedTue, Oct 23, 3:56 PM

This specification is a non-starter because Wikidata supports both the Gregorian and Julian calendar while this spec only supports the Gregorian calendar.

I'm not sure why that would be a problem - maybe there's a problem with what is understood by "support"? Adding support for particular Gregorian dates formatted in a particular way wouldn't affect the ability to set Julian dates as well.

That said, even level 0 support requires time interval support. When I add a date as 1964/2008 this is malformed in the date field. Wikidata expects you to use two separate properties to add a date range i.e. start time and end time. This seems a very big design decision to overhaul. The easiest way to accomplish this would be to support it in the front end with a wikidata specific gadget but it's less than ideal.

This is also true for things like quarters and seasons where you're currently expected to add the qualifier refine date. Rolling both of those features back into the date type in the back end seems difficult.

However, adding support for it in the backend would definitely make things like adding bibliographic data easier, particularly with any APIs that implement this format. We considered implementing an earlier version for citoid but got push back from citation template owners about supporting it and it's been stalled, but if wikidata supported it that'd be a big impetus to use it.

@Mvolz I'm not sure what you mean by front end and back end. In any case, there are several methods that may be used to put information into the database, and several that may be used to extract information from the database. Some of these methods like RDF follow standards set by external organizations and we lack the ability to change them.

Jc3s5h: This is now the third venue in which I have told you that there is absolutely no reason why we couldn't apply this only to Gregorian dates, as intended.

Jc3s5h: This is now the third venue in which I have told you that there is absolutely no reason why we couldn't apply this only to Gregorian dates, as intended.

And I will hunt down every place you have proposed this and make sure this serious disadvantage is mentioned. EDTF is human-readable. Humans have been using the same notation, in many formats and languages for Julian and Gregorian dates for 400 years, with ISO 8601 being one of the rare exceptions. And many ISO 8601 users are ignorant of the no-Julian restriction and therefore make mistakes. This human factors situation is an excellent reason to reject EDTF.

Pigsonthewing added a comment.EditedWed, Oct 24, 4:01 PM

ISO 8601 being one of the rare exceptions

As noted above: "ISO 8601-2019, due in the middle of that year, is expected to support all of the features of EDTF."

Furthermore, as you can read at the linked page: "the EDTF specification is included as a profile of ISO 8601."

ISO 8601 being one of the rare exceptions

As noted above: "ISO 8601-2019, due in the middle of that year, is expected to support all of the features of EDTF."

Furthermore, as you can read at the linked page: "the EDTF specification is included as a profile of ISO 8601."

My meaning was that nearly all notations, such as "July 1, 2018", "1 July 2018" "1 VII 2018" or "Solis Kandis Juliis MMXVIII" can refer to either the Gregorian or Julian calendar; this has been so for 400 years and that is what people are used to. ISO 8601 is one of the few notations that isn't supposed to be used with Julian dates; EDTF is another.