W3C home > Mailing lists > Public > public-i18n-ws@w3.org > December 2003

calendar dependent events scenarii - now with less fat!

From: A. Vine <andrea.vine@Sun.COM>
Date: Wed, 03 Dec 2003 18:34:05 -0800
To: public-i18n-ws@w3.org
Message-id: <3FCE9D1D.6070507@sun.com>

Here is the updated updated calendar dependent events scenarii, incorporating 
Addison's and Martin's comments.

Scenario I-0?? Calendar-dependent events

A Web service is set up to calculate a calendar date and send it back to
the requester.  The value returned represents a specific date on the calendar, 
not a timestamp value as might be associated with a particular locale or
timezone.  The service may need to take in information such as the calendar 
type, year, and related descriptive information.

Scenario A:  A service calculates the date for Easter, Passover, or Ramadan for 
any given year, returning a date value in {fill in the format, I don't know the 
right wording here}. These religious holidays are partly based
on astronomical events, such as lunar phases, as well as historical tables.
They are not strictly calendar dependent in the way that many secular holidays,
such as various national independence days or leader's birthdays are, nor are 
they predictable, for example, the fourth Thursday in November. Thus the need 
for a service to calculate the date might be necessary.  The
SOAP request would contain a holiday and a year in ISO 8601 format.  In 
addition, some other data may be required, such as for Easter there may be a 
parameter specifying "Orthodox" or "Western".  The Web service would in turn 
calculate the appropriate date and send a message back to the requester with the
calculated date.  Some other service may be used to convert the returned date 
value into a specified calendar type, such as the Japanese calendar.

Scenario B:  A service calculates historical dates in different parts of
the world and returns an equivalent ISO 8601 date to the
requester.  The SOAP request would contain a date and its country of
origin.  For example, a request might have the date 1812/08/26 and the
origin "Russia".  Russia was using a different calendar from places such as
Italy or France at that time; what would appear as the same date was actually 
several days off.  While this may look like it is part of the locale due to
the country of origin, it should not be treated as such.  Locales are
typically associated with the end user, not with a piece of data, and a
locale does not contain information on historical times.

Scenario C:  A service calculates Chinese New Year for any non-Chinese
calendar type.  The SOAP request would include a parameter with the
calendar type, such as "Gregorian", "Hebrew", or "Japanese Imperial".
The calendar type is again irrelevant to the locale, since the
requester may be looking for information unrelated to user preferences
or system settings. {in light of all the comments, I have no idea what to do 
with this scenario.  maybe we should replace it with Tex's scenario.}
Received on Wednesday, 3 December 2003 21:29:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:02:38 UTC