Wikidata talk:Extended Date-Time Format Specification

Questions from Yair rand

Tracked in Phabricator
Task T207705

[copied from Project Chat]

1. The section on "intervals" seems to be about showing a span of time, as in, A/B means that the thing started at A and ended at B. Is this correct? If so, how does one indicate a range of ambiguity, as in, it started at some time between A and B and ended some time between C and D? (Assuming the range isn't something that can be shown by X's instead of digits.) Does this use something with the [] syntax?
2. Does this work with other calendars? Presumably we'd need some custom extensions for calendars that are very different, but can it work for Proleptic Gregorian or Julian without issue? (Does it have a year 0?)
3. We currently theoretically store time zone data and specificity data as separate components in the data, I think. Would these be replaced?
4. If we're changing around the data model for dates, we should probably fix existing time zones. We don't actually support time zones in the UI yet, but all the data is claiming to be UTC even though it's not. EDTF supports both time zones specified and just indicating "local time". Should existing dates be switched to the latter?
5. Why does it have separate options for "Spring - Northern Hemisphere" and "Autumn - Southern Hemisphere" when those refer to the same time period?
6. Would we have the option to use the full set of syntax on any date statement? Could we use this to replace sourcing circumstances (P1480) circa (Q5727902), earliest date (P1319), latest date (P1326), and birthday (P3150)?
7. Are these dates easily convertible to other formats? Can it work with existing SPARQL queries? I imagine that some types might be difficult.
8. Are the devs on board with this?

--Yair rand (talk) 19:36, 23 October 2018 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘

1. AIUI [2004-06/2006-08]/[2011-04/..] (starting between June 2004 and August 2006; ending April 2011 or later)
2. No (or, at least, not yet). I proposed this, but the proposal was not accepted.
3. ?
4. That's for the community to discuss; see the Phabricator ticket, above.
5. Presumably because the drive for this came from library cataloguing; and that's what publications say on the cover.
6. Potentially, but let's take this one step at a time.
7. yes, and ?, respectively
8. Over to them...

-- Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:05, 23 October 2018 (UTC)

Yair rand asked "Does this work with other calendars? Presumably we'd need some custom extensions for calendars that are very different, but can it work for Proleptic Gregorian or Julian without issue? (Does it have a year 0?)" Julian or proleptic Julian, no. The ISO-8601:2004 which EDTF was meant to extend requires agreement among the user exchange partners to use years earlier than 1583, so does not support proleptic Gregorian absent such agreement. EDTF level 0 makes no mention of early years, so presumably the same extra consent is required. EDTF level 1 explicitly mentions a negative year, and years with more than 4 digits by prefixing "Y" to the year. So presumably stating that one is following EDTF level 1 is also consent to use years earlier than 1583, and thus the proleptic Gregorian calendar.

ISO 8601:2004 has a year 0, so EDTF has a year 0 as well. Jc3s5h (talk) 15:14, 25 October 2018 (UTC)

Vladimir's comments

@Pigsonthewing: "Primarily I want the community - especially devs - to discuss these issues"

Having a discussion is good. If WD can make a breakthrough in the handling of approximate/uncertain dates, that would be a boon to the historical/culture communities. But I think WD, which has a variety of date precisions, is already ahead of many other approaches/communities:

• VIAF has no approximate dates at all. You can only use the "standard" year/month/day precisions, that's all
• RDF has the same, with the datatypes xsd:gYear, xsd:gYearMonth, xsd:date. Anything more you need to model separately
• CIDOC CRM has an advanced model: crm:E52_Time-Span can have up to 4 date points: crm:P82a_begin_of_the_begin, crm:P81a_end_of_the_begin, crm:P81b_begin_of_the_end, crm:P82b_end_of_the_end; and there are textual qualifiers crm:P79_beginning_is_qualified_by, crm:P80_end_is_qualified_by. (The CRM itself (the spec) posits the existence of some all-powerful Date datatype in the underlying implementation, but the RDF rendition goes with these 4 date points.) But it's not adopted quite widely (i.e. there are few if any datasets to use all these props).

I think the biggest omission in WD right now is that you can't specify uncertain begin/end (eg 579-583 AD) unless it matches the current precision boundaries (eg decade) --Vladimir Alexiev (talk) 08:09, 25 October 2018 (UTC)

The data model includes spaces for that kind of data, but it's just not exposed by the UI yet, IIUC. For statements (not qualifiers), one can use earliest date (P1319) and latest date (P1326) as qualifiers. --Yair rand (talk) 20:19, 25 October 2018 (UTC)