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

[Don W. <don...@ma...>]

>
>
>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.
>
But is that not a different kind of information?
Mostly time will be used to specify an instant in time.
The data you provide could be part of observing-conditions?

>>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.
>
Not for specifying an instant of time.

>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.
>
I can see your point of using the local times. I'm just not sure if they 
specify the same kind of data and if not if they should be part of the 
same element.

>>>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.
>  
>
No, I think splitting of date and time is ok.  But even if no time is 
specified, timezone should be used for the date (if the date is not in UTC).

>>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.
>
Now that I understand your reasons for including the local times better, 
I'm not so sure anymore if we should include geographical data (in the 
time element). As long as we provide a 'non-local' time. Anyway as I 
said before, I think that these different time formats (local and 
not-local) should be in different elements as they are semantically 
different.

Don