Last modified: 2014-09-26 06:27:19 UTC
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.
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.
