Re: Calendaring I18N

Dear Robin,

The Internationalization Core WG has discussed your message, and  
realized that you've hit on a real problem for which we're not aware  
of an existing solution.

The main issues are:

- Not all calendars are defined in a way that makes it possible to  
convert individual time values to the Gregorian calendar. In the  
Islamic calendar, for example, the first day of a month traditionally  
depends on actual observation of the moon, so it can't be predicted  
with certainty. Countries using this calendar watch the moon  
separately, and some now rely on more predictable rules, so the  
location of an event also comes into play.

- Even where the mapping for a single time value follows predictable  
rules, rules for a recurring event often cannot be mapped to an  
equivalent rule in the Gregorian calendar, but instead would have to  
be represented as a (possibly infinitely long) series of time values.  
Take Chinese New Year, for example, a very important holiday in east  
Asia - it occurs every year, and follows rules that cannot be  
represented in the Gregorian calendar. It's the same problem as with  
Easter and Easter-related holidays, which follow different rules than  
the Gregorian calendar.

The correct solution obviously would be to store time values as field- 
based time in the relevant local calendar, along with an identifier  
for the calendar. As Felix already mentioned, CLDR [1] provides such  
identifiers for the calendars it supports - obviously a subset of the  
list you found on Wikipedia. However, this solution makes it  
impossible to process time information efficiently or to compare time  
values across calendars.

Time zones have a similar problem in that their definition can change  
(e.g. in their daylight savings rules) before a scheduled event occurs  
[2]. In this case, some systems are storing the time value as  
incremental time, but along with the time zone identifiers and the  
time zone offset assumed in calculating the incremental time value.  
This allows to verify later on whether the offset assumed is still  
correct, and adjust the stored incremental time value if necessary.

If you want to learn more about calendars, there's "Calendrical  
Calculations" by Dershowitz and Reingold.

It may be a good idea to set up a joint teleconference to discuss the  
issues in more detail.

Best regards,
Norbert

[1] http://www.unicode.org/reports/tr35/#Key_Type_Definitions
[2] http://www.w3.org/International/wiki/WorkingWithTimeZones#Past_and_Future_Events

-------------------------------------
Norbert Lindenberg
Yahoo! Internationalization Architect
Member W3C Internationalization Core WG


On Mar 23, 2010, at 03:46 , Robin Berjon wrote:

> Dear I18N WG,
>
> as part of its work, the DAP WG is creating a Calendar API that is  
> intended to be used by Web applications in order to interact with  
> calendar data. The current editors' draft can be found at http://dev.w3.org/2009/dap/calendar/ 
> .
>
> Our first instinct was to turn to iCalendar (RFC 5545) and other  
> related specifications in order to rely on tried and true practice  
> in the field. However, in the process of applying that information  
> to our work it surfaced that no existing standard that we have come  
> across to date seems to capture information relating to non- 
> Gregorian calendars.
>
> As you know likely better than we do, non-Gregorian calendars are in  
> common use throughout much of the world, and as far as we know it is  
> always possible to convert between them and Gregorian dates — which  
> makes the latter fine for internal storage. However, capturing the  
> calendaring system intended by the user when entering the date is  
> important as it may convey important semantics and will have impacts  
> on recurrence if for instance the specified non-Gregorian date does  
> not map to the same Gregorian day each year.
>
> Our current plan is to store dates as Gregorian, and use an  
> additional field to capture the user-intended calendar. The points  
> on which we would like to solicit your help are:
>
>  1) Is this a good and sane approach that will work?
>  2) Is there a list of calendars that we could use to provide a  
> definitive list of calendar names that implementations would be  
> expected to recognise? Wikipedia has a list [0] (from which  
> presumably we'd only take the "In current use" ones) but we'd like  
> to have some degree of certainty that it's complete and correct.
>
> Further, I would like to note that were it not for our Korean  
> participants, the group would not have been aware of the problem  
> regardless of how much we care about I18N. It seems to me that the  
> information we need to get this right for our specification may  
> benefit from being documented and shared with a wider readership.
>
> We look forward to your input on this issue, and thank you in  
> advance for any help!
>
> [0] http://en.wikipedia.org/wiki/List_of_calendars
>
> PS: Tracker, this takes care of ACTION-128.
>
> --
> Robin Berjon
>  robineko — hired gun, higher standards
>  http://robineko.com/
>
>
>
>
>

Received on Wednesday, 14 April 2010 06:59:51 UTC