Re: Calendaring I18N

I have set up a doodle poll for a meeting on calendar  
internationalization:
http://doodle.com/vinifwmdfitwv66a

It seems you have to allow cookies for doodle at least when creating a  
poll - the first time I went through the exercise it lost all my data  
three quarters of the way, without any prior warning.

Norbert


On Apr 14, 2010, at 06:26 , Robin Berjon wrote:

> 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, 21 April 2010 16:21:29 UTC