Re: Calendaring I18N

My first attempt hasn't seen enough response to lead to a meeting, so  
we have to try again.

Can everybody who cares about calendar internationalization please go to
http://doodle.com/vinifwmdfitwv66a
*NOW* and fill in their availability?

I'll announce the winning time in 24 hours.

John, Yoshito, Peter - Mark suggested inviting you.

Norbert



On Apr 21, 2010, at 09:20 , Norbert Lindenberg ♻ wrote:

> 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 Thursday, 29 April 2010 00:01:29 UTC