Re: Calendaring I18N

I just talked to Addison - since it seems very difficult to get all  
key people into a conference call, we'll abandon that plan for now and  
start a W3C wiki page instead where people can contribute  
asynchronously. Look forward to a URL some time next week.

Sorry about the detour, and enjoy the weekend!

Norbert



On Apr 29, 2010, at 19:44 , Norbert Lindenberg ♻ wrote:

> Thanks to all who doodled!
>
> First choice: The slot that got the highest number of votes is
> 2010-05-04T15:00:00Z, but unfortunately that does not include Robin or
> any other DAP WG member. Robin, any chance you can make this time
> possible?
>
> Second choice: The best times that would include Robin are
> 2010-05-03T14:00:00Z and 2010-05-04T14:00:00Z. So if Robin cannot make
> the first choice possible, then let's use 2010-05-03T14:00:00Z.
>
> Robin, your call.
>
> Norbert
>
>
>
> On Apr 28, 2010, at 17:00 , Norbert Lindenberg ♻ wrote:
>
>> 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 Friday, 30 April 2010 18:04:10 UTC