daniel added a comment. You are right about the potential data-loss when copy&pasting the data back. A couple of thoughts about that:
1. While allowing full round trips without loss is nice, it's not something we are absolutely committed to. In particular, the "pretty" HTML display of our complex value types (time, geo, quantity) are all lossy (geo loses the reference globe, time loses before/after, etc). 2. Since the display of the calendar model is omitted in cases where the calendar model isn't relevant (precision of year of larger), getting the calendar model wrong wouldn't be much of a problem. It would be nicer to have a "Grego-Julian-whatever" model for such cases, but I'm afraid that would introduce more issues than it solves. Anyway. I agree that we could change the heuristic of when to show the calendar model so that the calendar is always shown when it's not the default (and maybe in some other cases too). That should fix the round trip issue. I agree that we should probably change the "edge" to 1583-01-01. The switchover-date was in October, closer to 1583-01-01 than to 1582-01-01. In reality however we just don't know what calendar was used for dates given around 1600; it was probably simply a mess. The one thing I really disagree with is the we should re-implement the old heuristic exactly. In particular, dates before 1582 (resp 1583) should not default to Gregorian, no matter what their precision is. TASK DETAIL https://phabricator.wikimedia.org/T75272 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign <username>. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: thiemowmde, Wikidata-bugs, Tobi_WMDE_SW, Jc3s5h, Lydia_Pintscher, aude _______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
