Re: [Xmlastro-discussion] It's about time.

[Peter C. C. <pc...@ec...>]

On Wed, 2 Apr 2003, Don Willems wrote:

> >I introduced restricted versions of xs:datetime, xs:date, and
> >xs:time to control the time zone option. I feel that observers should
> >always include time zone information unless they are specifically
> >recording a local time. I provide different elements for local times to
> >distinguish them from "absolute" times
>
> I don't see that. I would expect timezone information to be included
> specifically with local times (LST). If you're using LAT or LMT I'd
> expect geographical information to be included.

My concept was that most of the time the <ISO> option would be used. That
option requires time zone information. Local times would be employed only
rarely and under special circumstances. For example, in a day-to-day
observation I might record date/time as

<datetime>
  <ISO>2003-04-04T20:30-05:00</ISO>
</datetime>

I don't regard this as a local time even though it's using the -0500 time
zone... which happens to be my local time zone. Unlike a "local"  time,
the time quoted above is intended to specify one unique moment. There are,
however, some things for which only a true local time makes sense. For
example if I say something like "the radiant is only in a good position
for observing after 22:00 local standard time," I'm *not* trying to
specify a unique moment. The local time 22:00 occurs at a different moment
in every time zone... yet the statement is still true. The radiant is well
positioned at a different moment in every time zone; using a universal
time to describe such a thing is impossible.

Another potential place where a true local time makes sense is in
describing twilight. At what time is twilight over? Using a universal time
for that would not be very enlightening and would be somewhat unnatural.

I admit that my proposal contains quite a few "exotic" local time
options... most of which would probably rarely be used.

> Anyway I'm not so sure about all these formats. If I want to include
> time information of the observation I'd expect at least LST or JD and
> preferrably UTC.

Really what you'd want is the <ISO> option or the <JD> option. You
definitely don't want the <LST> option.

> Should we make one of these time formats required and the others LAT,
> LMT,... optional? For times included in a position LAT or LMT should not
> even be allowed to be included in the time information. At least that is
> my opinion.

Certainly it makes no sense to use a local time in a position. On the
other hand I think there are situations where it makes no (or little)
sense to include an absolute time with a local time. Perhaps we are trying
to cover too much ground with one element. Or perhaps this is an example
of a constraint that must be applied externally to the schema.

> >It will be common, I think, for a set of observations to occur at
> >different times on the same date. Note that the time zone information is
> >inherited by the observation as well as the date.
> >
> I'm sure if we should do this. Timezone information is not that much, so
> it shouldn't be to much of a problem to include it in every local time
> (LST). It will make the information more readable.

I was more worried about the date than the timezone information. On the
other hand since the date changes at local midnight... right in the middle
of the night... tagging each observation with a full datetime might make
sense. You've expressed reservations about splitting up dates and times
before and I'm fine with dropping that (mis?)feature.

> Maybe we should include geographical information?

Certainly the geographical information will influence the interpretation
of some time formats just as time influences the interpretation of some
position formats. Ideally an observer would include all relevant
information in all observations. I'm not sure, though, how far we can go
in enforcing that with the schema.

Peter