It is quite common to set Gregorian dates as equal to ISO8601 dates, and this is correct as long as you only go forward from 1582. If you want to go backwards you must do so only after negotiation with the communicating peer, that is "do as we say if you want our data!" When you hit 1BC the ISO8601 goes to +0, but "hey - do you want our data or what?"
If we want to be really picky about dates, or any value, then there are systems, model and datum. The model is how we describe something, and the datum is a specific set of arguments for the model. Both are often assumed within a system, like the SI system, but often there are bunch of updates and modifications. If there is a best precision then a lot of the models and datums collapse into a single one, like if you have a date with only year precision. /me digs in on another project John On Wed, Jul 1, 2015 at 10:12 PM, Markus Krötzsch <[email protected]> wrote: > On 01.07.2015 20:08, John Erling Blad wrote: >> >> Wouldn't it be better to use iso8601 as internal format? > > > Yes, that was essentially our original proposal. ISO8601 is a syntax for > proleptic Gregorian dates, so this would be the internal calendar model. ISO > has no such detailed way to specify precision, so this was an add-on we > conceived for Wikidata as an optional annotation to the exact date). The > idea was that all type "date" just means "ISO date + precision" and that > Julian calendar support is provided by offering transparent conversion > functions to the user (so you could always see and write Julian dates if you > wanted to, without this changing the internal ISO form). The additions of > "before" and "after" came later. The key idea to use ISO format internally > while still supporting Julian dates with perfect round-tripping is > implemented in Semantic MediaWiki, and the plan was to do this in Wikidata > as well. > > That was the theory. In practice, there was the confusion that Lydia > described. Maybe the main problem was that bot authors were writing the > internal data directly (for a while this was almost unfiltered). So when > they would use the API like a user would use the UI ("set 'Julian' if you > want to input your date in Julian"), then it would be wrong, since they > would bypass the Julian conversion that the UI provided. This might have > been the seed for the confusion that arose. This is only of historic > interest now; we don't need to discuss where exactly the errors happened > first. Better focus on fixing the dates now. > > Best regards, > > Markus > >> >> >> ons. 1. jul. 2015, 18.45 skrev Markus Krötzsch >> <[email protected] <mailto:[email protected]>>: >> >> On 01.07.2015 18:14, Peter F. Patel-Schneider wrote: >> > On 07/01/2015 07:00 AM, Pierpaolo Bernardi wrote: >> >> On Wed, Jul 1, 2015 at 8:17 AM, Markus Krötzsch >> >> <[email protected] >> <mailto:[email protected]>> wrote: >> >>> Dear Pierpaolo, >> >>> >> >>> This thread was only about Julian and Gregorian calendar dates. >> If and >> >>> how other calendar models should be supported in some future is >> >>> another (potentially big) discussion. As you said, there are many >> >>> issues there. Let's first make sure that we handle the "easy" >> 99.9% of >> >>> cases correctly before discussing any more complicated options. >> >> >> >> Lydia Pintscher in the starting email explained that there's a >> model for >> >> calendars, and unfortunately this model could be (and has been) >> >> interpreted in two ways (AFAIU). >> >> >> >> My intention was to point out that one of the two >> interpretations is not >> >> sound. This leaves the other one as the only viable one. >> >> >> >> Cheers P. >> > >> > It appears (from the email only---there are no pointers to enduring >> > documentation on the solution that are attached to the relevant >> classes or >> > poperties) that the chosen method is to store dates in both the >> source >> > calendar and the proleptic Gegorian calendar >> > >> >> (https://www.wikidata.org/wiki/Wikidata:Project_chat#calendar_model_screwup). >> > As you point out, this is not a viable solution for calendars >> whose days do >> > not start at the same time as days in the proleptic Gegorian >> calendar >> > (unless, of course, there is time and location information also >> available). >> >> The Wikidata date implementation intentionally restricts to dates that >> are compatible with the Gregorian calendar. Although the system refers >> to Wikidata item ids of calendar models to denote "Proleptic >> Gregorian" >> and "Proleptic Julian", the system does not allow users or bots to >> enter >> arbitrary items as calendar model. >> >> My understanding (and the implementation in WDTK) is that all dates >> are >> provided in Gregorian calendar with a calendar model that specifies >> how >> they should be displayed (if possible). The date in the source >> calendar >> is for convenience and maybe for technical reasons on the side of the >> PHP implementation. At no time should the source calendar date be >> impossible to convert to Gregorian. We have had extensive discussions >> about this point -- Gregorian must remain the main format at all >> times. >> >> This does not mean that we cannot have more models in the future. >> There >> is (currently unused) timezone information, which can be used to store >> offsets. Once fully implemented, this might allow exact conversion >> from >> calendar models that have another start for their days. So maybe this >> is >> not a case of real incompatibility. However, the timezone support for >> current dates needs to be finished before discussing the next steps >> into >> more exotic calendars. >> >> Best regards, >> >> Markus >> >> >> _______________________________________________ >> Wikidata mailing list >> [email protected] <mailto:[email protected]> >> https://lists.wikimedia.org/mailman/listinfo/wikidata >> >> >> >> _______________________________________________ >> Wikidata mailing list >> [email protected] >> https://lists.wikimedia.org/mailman/listinfo/wikidata >> > > > _______________________________________________ > Wikidata mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikidata _______________________________________________ Wikidata mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata
