Re: calendar *dependent* events scenarii

The ranges are funny, and XMLSchema and ISO 8601 sorta punted. The problem is
that when someone implicitly treats a date as translateable to a range that it
gets a bit gummy.

When someone typically refers to a date, e.g. July 12, 1962, even when fully
specified (GMT), they don't really mean all points in time between July 12, 1962
00:00:00 GMT and July 13, 1962 00:00:00 GMT (half-open interval); they typically
mean that some event transpired during that time, e.g. that the event overlapped
with the full range. Thus the fact that Joe was born on that date means that
there was some time during that date when he was born, not that he was being
born through the entire period.

Now in normal usage, this is not much of an issue, simply because the dates are
uninterpreted. But when one starts to use the arithmetic functions on them or
translate timezones, it starts to give funny results. If Joe was born at 01:00
am that night, then he was born on July 11, 1962 (in pacific time); he wasn't
born "on" July 11, 1932 17:00:00 through July 12, 1962 17:00:00, Pacific Time,
although he was certainly born at some time during that interval.

Anyway, that was all a digression. Java doesn't really represent this either,
since a Date (and a Calendar) always refers to a specific point in time, not a
date with an undetermined time.

In ICU4J we do have classes that represent 'indirect' times, like the 2nd
Tuesday in the month, or the 2nd to the last Tuesday in the month. If you want
to represent something like the observed Columbus day, which is formally on X
day, but is observed on the closest Friday or Monday, then you need something
like this. But that is a way, if you will, of computing the actual day. I
suspect the example you use would just serve up actual days.

Mark
__________________________________
http://www.macchiato.com
► शिष्यादिच्छेत्पराजयम् ◄

----- Original Message ----- 
From: "Addison Phillips [wM]" <aphillips@webmethods.com>
To: "Mark Davis" <mark.davis@jtcsv.com>; <andrea.vine@Sun.COM>;
<public-i18n-ws@w3.org>
Sent: Tue, 2003 Nov 25 12:22
Subject: RE: calendar *dependent* events scenarii


Hi Mark,

The point of the scenario isn't the usefulness index, although we would like for
the service described to have some utility (and not be a meaningless example).
The point is actually to draw a distinction between values that are
point-moments in time (January 3, 1956 at 10:23:47 PM Pacific Standard
Time---what in Java you'd call a java.util.Date) and "calendric" moments ("the
Fourth of July", people's birthdate, etc--what in Java you might use a
java.util.Calendar to represent)

These require slightly different data types in XML Schema and, of course,
different handling in code.

But state holidays in Utah are a good example too.

Addison

>
>
> I don't know that the calendar scenario is actually that useful;
> most OSs have a
> variety of calendars already. What would be a more compelling
> example would be a
> server for 'business holidays', since those are not generally
> supported, and
> vary by country and even by smaller units: states/provinces, even
> cities; and
> may need updated frequently.
>
> E.g. get me the state holidays in Utah.
>
> Mark
> __________________________________
> http://www.macchiato.com
> ► शिष्यादिच्छेत्पराजयम् ◄
>
> ----- Original Message ----- 
> From: "Addison Phillips [wM]" <aphillips@webmethods.com>
> To: <andrea.vine@Sun.COM>; <public-i18n-ws@w3.org>
> Sent: Mon, 2003 Nov 24 21:25
> Subject: RE: calendar *dependent* events scenarii
>
>
> >
> > Hi Andrea,
> >
> > Great stuff. Some suggestions on the intro and first scenario below.
> >
> > Addison
> >
> >
> > > 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.
> > >
> >
> > Perhaps "The value returned represents a specific date on the
> calendar, not
> > a timestamp value as might be associated with a particular locale or
> > timezone."??
> >
> >
> > > 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.
> >
> > I don't think the intro to Scenario A quite captures it. I
> think we need to
> > draw the distinction with fixed-date events. Maybe:
> >
> > A service calculates the date for Easter, Passover, or Ramadan
> for any given
> > year in a specified calendar type. These religious holidays are
> partly based
> > on astronomical events (such as lunar phases) as well as
> historical tables
> > and not strictly calendar dependent (in the way that many
> secular holidays,
> > such as various national independence days or leader's birthdays are) or
> > predictable (third Thursday in November, etc.). Thus the need
> for a service
> > to calculate the date might be necessary. // continue with... "The SOAP
> > request..."
> >
> > > 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.
> > >
> > >
> > >
> >
> >
>

Received on Tuesday, 25 November 2003 15:44:13 UTC