Re: data expression of date information

At 11:13 AM 2002-12-19, John Cowan wrote:
>Al Gilman scripsit:
>
> > 4. Warning: omitting localOffset is legitimate in planDateTime if a 
> location
> > is given in geographic terms.  This is the "when it's noon in Boston" usage
> > as opposed to "17:00 UTC" or "12:00 -05" usage.  But I don't think that 
> this
> > needs to be anything more than a remark in defining how to express past 
> events
> > in EARL.
>
>The point I was trying to make to Al (maybe a little confused by the
>circumstances) was that date+offset is adequate for *past* times, but
>inadequate for future ones.  If I make an appointment to meet you in Times
>Square at midnight 2005-01-01, that is not equivalent to saying I'll meet
>you at 2005-01-01 05:00 UTC.  The U.S. might change the time zone rules
>between now and then -- unlikely but not impossible, given that it did
>just that in 1974-75, extending daylight savings time for most of the year.
>
>There is no resolution in principle for this, but using the historically
>based time zone names of the ADO (GNU) time zone library, like
>America/New_York, provides the best hope.

Sorry, what do you mean by a 'resolution'? at this point?  Maybe there is a
resolution or there is no resolution.  If it's a way out of a predicament,
there is a resolution.  If it's an unambiguous mapping to UTC time, there is
no resolution, but no need of a resolution.  Thus the fact that the
resolution is a reference to possibly future utterances of the civil
authority is true, but not a problem.

No.  This is what we went around on before.  There _is_ at least a
resolution in practice and, depending on the sense of the term 'resolution,'
in principle.

It has to do with understanding the point or use of the time reference in a
plan.  The purpose is to provide or participate in a set of constraints
sufficient to assure the achievement of a rendezvous.

John, this is what you and I discussed before.

The resolution is that the place and local time is sufficent as a policy for
how to rendezvous, and it is a rendezvous policy that is what goes in a
plan, *not* necessarily an _unambiguous_ *time* reference.  The offset
policy of the civil authority will be definitized in time to accomplish the
rendezvous transaction of both being at the agreed meeting point at the same
time.

The time reference will be unambiguous by the time that the rendezvous is
consummated.

UTC Date plus offset is also logically sufficient for a rendezous agreement,
but not customary, so the terms of an agreement on these terms will have
to be emphasized for people to follow them.

Al

>It is especially significant
>that ADO divides time zones by country, since it is the country that
>is responsible for assigning local times.  Thus, Europe/Paris currently
>behaves just the same as Europe/Copenhagen, but it has not always been
>so and may not be so in future.
>
>See ftp://elsie.nci.nih.gov/pub for downloadable ADO time zone information.
>The latest file is tzdata2002d.tar.gz

Thank you for this helpful reference.

Al

>--
>John Cowan                              <jcowan@reutershealth.com>
>http://www.ccil.org/~cowan              http://www.reutershealth.com
>Unified Gaelic in Cyrillic script!
>         http://groups.yahoo.com/group/Celticonlang

Received on Thursday, 19 December 2002 13:51:21 UTC