- From: Norbert Lindenberg ♻ <norbert.lindenberg@yahoo-inc.com>
- Date: Wed, 28 Apr 2010 17:00:40 -0700
- To: public-i18n-core@w3.org, public-device-apis@w3.org, Yoshito Umaoka <yoshito_umaoka@us.ibm.com>, Peter Edberg <pedberg@apple.com>, John Emmons <emmo@us.ibm.com>, Mark Davis ☕ <mark@macchiato.com>
- Cc: Robin Berjon <robin@robineko.com>, Norbert Lindenberg ♻ <norbert.lindenberg@yahoo-inc.com>
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:02:07 UTC