Re: calendar *dependent* events scenarii

Hello Andrea,

Some comments below:

At 18:10 03/11/24 -0800, A. Vine wrote:


>All,
>Here is the updated calendar dependent events scenarii, incorporating 
>Tex's comments.
>Andrea
>
>
>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 date is calendar-dependent but is not 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 in a specified calendar type.  All these
>holidays are strictly calendar-dependent; they are calculated based on
>certain calendar and lunar events, as well as historical tables.  The
>SOAP request would contain a holiday, a year, and a parameter indicating
>the calendar type, e.g. "Gregorian".  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.  It may seem as though the calendar type is a part of
>the locale information, but locale information is typically associated
>with the end user, and there's far more information in a locale than is
>needed. In this case, the calendar type is irrelevant to the locale,
>since the requester may be looking for information unrelated to user
>preferences or system settings.

I'm quite confused here. Is the request to get back e.g.
Western Easter in the Thai Buddhist calendar, or Ramadan
in the Julian calendar,...? Isn't this just a conflation of
two separate tasks, namely a) getting the date(s) of the event
in a locale-neutral form (i.e. ISO 8601 / XML Schema date format),
and b) converting these dates to the desired calendar?


>Scenario B:  A service calculates historical dates in different parts of
>the world and returns an equivalent Gregorian calendar 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 not using the Gregorian calendar at that
>time, so that date is not equivalent to the same date in places such as
>England or Germany.

This seems to imply that England and Germany were using Gregorian
at that time. They probably did (or for Germany, at least a significant
part did), but I guess replacing 'England or Germany' with 'Italy or France'
puts us on the safe side.


>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.  A
>locale contains far more information than is relevant to this
>calculation as well.

I think the 'a locale contains far more information' is quite irrelevant.
I guess that for all the examples in all the scenarios we use, this
would actually be true.
I think what's more important is that historical times are most
probably not covered by locale information.


>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.

Again, this conflates two separate tasks in the same way Scenario A does.


Regards,    Martin.

Received on Tuesday, 25 November 2003 15:41:23 UTC