Re: Calendaring I18N

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 02:45:38 UTC