Jc3s5h added a comment.

I would agree with @thiemowmde if there were a plausible alternative to the 
Gregorian and Julian calendars which might require support in the future. But I 
believe that any such alternative would be so drastically different that there 
would be no temptation to apply the proposed generic support (e.g. any February 
may have up to 29 days). Thus, if we were willing to do the work to provide 
different validation for Gregorian and Julian, there would be minimal risk of 
having to create a large number of variations on the theme.

About thiemowmde's comment above "It may make sense to store such a date [31 
February], for example if a source states a person was born on "31 February". 
We want to store that, even if it's wrong." It seems to me the purpose of a 
database is to store the best available conclusion, in a calendar that is, or 
can be converted to, the Gregorian calendar. Discussion of the merits of 
various pieces of evidence is fine for history journals, or even a Wikipedia 
article, but doesn't seem appropriate for Wikidata in its current state. If 
that sort of thing ever belongs in Wikidata, I think it should be part of an 
enhanced reference system that provides an opportunity to explain how the text 
that appears in the source was transformed into the data stored as a Wikidata 
property.

In cases, such a the birth date of Augustus, where a specific day is named but 
it can't be transformed into the Gregorian calendar, I think the birth date 
should be given as a Julian or Gregorian date with looser precision.


TASK DETAIL
  https://phabricator.wikimedia.org/T85296

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Jc3s5h
Cc: Lydia_Pintscher, Jc3s5h, Liuxinyu970226, Ricordisamoa, Addshore, 
thiemowmde, JanZerebecki, Aklapper, daniel, Smalyshev, Wikidata-bugs, aude, 
Malyacko



_______________________________________________
Wikidata-bugs mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

Reply via email to