Calendars may use different representations of time; For each calendar, there would be a well defined internal representation (as a DataValue of some time), complete with renderers and parsers. For the gregorian Calendar for instance, there could be an IsoTimeValue.
Formatters/parsers for the "inner" time would take care of localization. The "outer" formatter/parser would take care of the precision/range, the time zone (really?), and the calendar model.
Version: unspecified
Severity: normal
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Invalid | hoo | T61766 Support for months and years of a different calendar | |||
| Open | None | T87764 Bugs related to time datatype (tracking) | |||
| Open | None | T59930 Representation of time inside TimeValue objects should depend on the calendar model | |||
| Invalid | None | T126445 Allow selection of value parser, validator, and formatter to depend on the data value itself. |
I believe it shall be different data type. Default datatype (used for p569/p70 of real people) should have consistent uniform intenal represantation (current, for example) that does not depends on calendar model. It's the only wayto make range queries simple and fast.
Proposeto change priority from normal to low because of that and raise priority of fixing the ui calendarmodel conversion and display.
Regarding using different data types: Calendars basically identify sub-types, just like units identify sub-types of Quantity, and globes identify sub-types of Geo. Modelling the idea of sub-types more explicitly would be useful in cases when specialized parsers or formatters should be used based on the sub-type.
Range queries can not be done on raw values anyway, the can and should only be done on normalized values, see T89005: [Story] JSON should (optionally) contain expanded/normalized values..
The description includes "the time zone (really?)" I infer the person who wrote that doesn't think time zones are very important. I, on the other hand, believe every date currently in Wikidata is false, except those close to 0° longitude, because they all say that the event occurred in a certain date time zone 0. I have not seriously begun correcting birth or death dates because Wikidata is currently incapable of storing the correct values.