RE: Calendaring I18N

Hello Robin,

(chair hat on)

I have added this item to our WG's discussion for today's teleconference.

(chair hat OFF)

In addition to considering calendar, it's very important in calendars to consider the effect of time zone (as well as the internal representation of time). For more information, see our draft update to the note on "working with time zones":

   http://www.w3.org/International/wiki/WorkingWithTimeZones


This is important in implementing a calendar API, especially when it comes to dealing with "floating time events".

More directly on topic: I think your approach can work and Felix's recommendation of using CLDR as a reference point is a good one.

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.


> -----Original Message-----
> From: public-i18n-core-request@w3.org [mailto:public-i18n-core-
> request@w3.org] On Behalf Of Robin Berjon
> Sent: Tuesday, March 23, 2010 3:46 AM
> To: public-i18n-core@w3.org
> Cc: public-device-apis@w3.org
> Subject: Calendaring I18N
> 
> Dear I18N WG,
> 
> as part of its work, the DAP WG is creating a Calendar API that is
> intended to be used by Web applications in order to interact with
> calendar data. The current editors' draft can be found at
> http://dev.w3.org/2009/dap/calendar/.

> 
> Our first instinct was to turn to iCalendar (RFC 5545) and other
> related specifications in order to rely on tried and true practice
> in the field. However, in the process of applying that information
> to our work it surfaced that no existing standard that we have come
> across to date seems to capture information relating to non-
> Gregorian calendars.
> 
> As you know likely better than we do, non-Gregorian calendars are
> in common use throughout much of the world, and as far as we know
> it is always possible to convert between them and Gregorian dates —
> which makes the latter fine for internal storage. However,
> capturing the calendaring system intended by the user when entering
> the date is important as it may convey important semantics and will
> have impacts on recurrence if for instance the specified non-
> Gregorian date does not map to the same Gregorian day each year.
> 
> Our current plan is to store dates as Gregorian, and use an
> additional field to capture the user-intended calendar. The points
> on which we would like to solicit your help are:
> 
>   1) Is this a good and sane approach that will work?
>   2) Is there a list of calendars that we could use to provide a
> definitive list of calendar names that implementations would be
> expected to recognise? Wikipedia has a list [0] (from which
> presumably we'd only take the "In current use" ones) but we'd like
> to have some degree of certainty that it's complete and correct.
> 
> Further, I would like to note that were it not for our Korean
> participants, the group would not have been aware of the problem
> regardless of how much we care about I18N. It seems to me that the
> information we need to get this right for our specification may
> benefit from being documented and shared with a wider readership.
> 
> We look forward to your input on this issue, and thank you in
> advance for any help!
> 
> [0] http://en.wikipedia.org/wiki/List_of_calendars

> 
> PS: Tracker, this takes care of ACTION-128.
> 
> --
> Robin Berjon
>   robineko — hired gun, higher standards
>   http://robineko.com/

> 
> 
> 
>

Received on Wednesday, 24 March 2010 15:47:19 UTC