Re: calendar *dependent* events scenarii

Yes, it is tricky.

> Alas xsd:date allows a timezone identifier...

An (optional) timezone identifier is actually reasonable. Stating that it is
July 12, 1999 GMT does convey different information than just July 12, 1999
(undetermined zone), or than July 12, 1999 Pacific Time.

Note that July 12, 1999 08:00 Pacific Time is very different than July 12, 1999
08:00 GMT-08:00. You see that when you start to set up a repeating meeting, such
as in calendar software. If we meet every month on the 12th at 08:00 PT, that
will be sometimes 8:00 GMT-08:00 and sometimes 07:00 GMT-08:00. And in most
cases, PT is what people want instead of GMT-08:00.

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 13:02
Subject: RE: calendar *dependent* events scenarii



XML Schema does a lackluster job of explaing any of this.

I probably wouldn't use ranges for a calendric (non-point) date value. I'd
probably use the 'xsd:date' type in preference to a 'xsd:dateTime', e.g.
'2003-11-25' instead of '2003-11-25T00:00:00Z'. The point then is that you
should not interpret a calendric date using a time zone (either your local one
or some other value). Alas xsd:date allows a timezone identifier...

This is contrary to most date arithmetic in Java and other programming
languages, where dates are, as you say, generally just of the point type and you
must interpolate the 'right value' from a specific date object or apply the
correct usage based on implementation decisions. There is some question, for
example, of whether midnight GMT or noon GMT is a better 'default' value for a
date object representing a 'calendric value' like this (since noon actually
falls during the day for nearly all time zones, whereas midnight doesn't affect
the bits in the underlying long integer value).

In any case, the mere fact that we're having this discussion points up the fact
that most developers have, in my experience, a lot of trouble with date,
datetime, timezone, and related event-driven issues: this is a neglected topic
of discussion. It's nice to explain some of it.

Addison

Addison P. Phillips
Director, Globalization Architecture
webMethods | Delivering Global Business Visibility
http://www.webMethods.com
Chair, W3C Internationalization (I18N) Working Group
Chair, W3C-I18N-WG, Web Services Task Force
http://www.w3.org/International

Internationalization is an architecture.
It is not a feature.

> -----Original Message-----
> From: Mark Davis [mailto:mark.davis@jtcsv.com]
> Sent: mardi 25 novembre 2003 12:44
> To: aphillips@webmethods.com; andrea.vine@Sun.COM; public-i18n-ws@w3.org
> Subject: 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 18:47:43 UTC