Re: Calendaring I18N

Hi Norbert, I18N,

thank you all for the very valuable information you've provided us with. Clearly, there's work to be done!

On Apr 14, 2010, at 08:59 , Norbert Lindenberg ♻ wrote:
> 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.

We were afraid you'd say that :)

> - 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.

This is just a thought off the top of my head, and it might be a very bad one, but I think that there's a subset of these dates that can be algorithmically mapped. It may be a tall order for us to require from all implementations that they support all of these algorithms, but it might be that we can work around that. To take your example with (Western) Easter, perhaps something along the lines of the following could work:

// takes a date and returns true if it's Western Easter
// NB: untested, ported from Perl with mostly search and replace
function isWesternEaster (date) {
    var year = date.getFullYear();
    var goldenNumber = year % 19;
    var quasiCentury = (year / 100).toFixed();
    var epact = (quasiCentury - (quasiCentury/4).toFixed() - ((quasiCentury * 8 + 13) / 25).toFixed() + (goldenNumber * 19) + 15) % 30;
    var interval = epact - (epact/28).toFixed() * (1 - (29/(epact+1)).toFixed() * ((21 - goldenNumber)/11).toFixed());
    var weekday = (year + (year/4).toFixed() + interval + 2 - quasiCentury + (quasiCentury/4).toFixed()) % 7;
    var offset = interval - weekday;
    var month = 3 + ((offset+40)/44).toFixed();
    var day = offset + 28 - 31 * (month/4).toFixed();
    return date.getMonth() == month && date.getDate() == day;
}

date.addReminder({
   // regular reminder stuff (bells because it's France)
   description: "Go look for the eggs the bells have brought",
   // repeat rule is tested daily
   repeatRule: isWesternEaster,
   granularity: "daily",
});

The idea here is that third party libraries could be developed for just about any calendar event from the more common like Easter above to the more exotic such as calculating St. Tib's day in the Discordian calendar. This is *potentially* attractive because it simplifies implementation and specification, while still making it possible for services to expose the full wealth of calendaring systems that we have.

Now there are about a bazillion and a half issues with the above. There are security issues about the code being run in a different context, there's carrying the context around so that it can run, problems with whether it could access the network or not (e.g. to get up to date information, for instance about the start of Ramadan) and if so under what rules, not to mention how such reminders would go about being saved to existing file formats in order to be exchanged.

So before we even think about this as an option, we would be interested in knowing whether you think it would be a (relatively) sane approach, and roughly how big a chunk of the problem it would solve.

> 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.

I see two potential problems with the CLDR (I'm not sure they're problems, but I want to ferret issues out). One is that the list seems surprisingly short. For instance, the first use case we received in this area concerned the Korean lunisolar calendar which I don't see in the list. It might be that it's equivalent to another in the list — that's not entirely clear. The other issue is that, as you no doubt know, for a WG a correct solution is one that gets implemented. If we need to define a separate interface for each (major) calendar and then provide the means to integrate all this information (if only so that it can be represented within a single UI) then we're in trouble :) Don't get me wrong, if it's the only way, then it's the way, but I would very much like if possible to find an option simpler than the exhaustive listing of calendaring systems. Further, given that if we don't ship a calendar API others will (likely with little or no I18N consideration whatsoever) if this is going to be a time-consuming piece of work I would like to find ways to orthogonalise it from "core" (for lack of a better word) parts of the API. It makes me cringe to hear "80/20" and "I18N" in the same sentence, but if you could help us find an architectural and incremental approach to this issue instead of an exhaustive take it would be extremely helpful.

One thing that I'd like to know is how implementations actually handle this today. We've seen that for several calendars there is UI support, but we don't know if they exchange the information and if so how. Would someone with access to an iCal/Outlook with support for non-Gregorian calendars mind sending me an invite to a recurring event in that calendar (e.g. lunisolar) so that I can look at how it's stored?

> 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.

Yes, we've been thinking about this problem, notably the fact that when using a Javascript Date object the TZ information is lost. This is tracked by our ISSUE-81.

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

Thanks for the pointer, I might just buy it. Shame there isn't a Kindle version.

Apparently there's pretty good support for I18N calendars somewhere in Emacs, but I'm afraid to look. Volunteers welcome!

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

Yes, I think we'll need it. Should we try organising this with a Doodle or some such?

--
Robin Berjon
  robineko — hired gun, higher standards
  http://robineko.com/

Received on Wednesday, 14 April 2010 13:27:13 UTC