Re: An approach to xsd:dateTime

On 25 Jul 2008, at 13:33, Deborah L. McGuinness wrote:

>
> ps.  if i do not have a time zone, i can look for the location of  
> the instrument / observatory that generated it and then figure out  
> time zone based on lat / long and date of instrument.
> we currently do not have moving instruments yet.
>

good - so if you were to do this, you could (with no overhead to speak  
of),

- instead of adding the timezone information
- convert the time in the 'owl-standard-time-zone-time'

Hence not having time zones shouldn't be a huge problem?!

Cheers, Uli

> Alan Ruttenberg wrote:
>> Hi Deb,
>>
>> Could you say a bit about how the datetime data is used? Are you  
>> simply doing retrieval? Sorting (if so, how to compare those with/ 
>> without timezone?)
>>
>> Best,
>> Alan
>>
>> On Jul 25, 2008, at 7:45 AM, Deborah L. McGuinness wrote:
>>
>>>
>>> My applications make heavy use of xsd datetime.
>>> my issue in applications is that i have unpredictable data details.
>>> sometimes i have year, month, day,  (sometimes with and sometimes  
>>> without timezone)
>>> and sometimes i also have hour and minutes (and sometimes even  
>>> seconds) sometimes with and sometimes without timezone.
>>>
>>> so i would NOT support a requirement that all data either does or  
>>> does have a time zone ;
>>> i would support an approach that allows me to have optional  
>>> timezones.
>>>
>>> thanks,
>>> deborah
>>> Michael Smith wrote:
>>>> On Thu, 2008-07-24 at 12:27 +0100, Uli Sattler wrote:
>>>>
>>>>
>>>>> the 'easy' support for time that I was advocating yesterday  
>>>>> seems to  fit in nicely with this:
>>>>>
>>>>> - absence of a time zone (so I guess we would only support a   
>>>>> *restriction* of xsd:dateTime, but this should be ok)
>>>>>
>>>>
>>>> I think we either need all constants to have a timezone, or  
>>>> none.  I
>>>> prefer the first based on the assumption that more data "in the  
>>>> wild"
>>>> has timezones, and that such data is more completely defined.
>>>>
>>>>
>>>>> - the value space is continuous (since seconds are decimals  
>>>>> between 0  and 60, according to my reading of Mike's [1]) and  
>>>>> therefor, from an  algorithms perspective, isomorphic to  
>>>>> owl:number and thus it shouldn't  be too much of a burden on the  
>>>>> implementors.
>>>>>
>>>>
>>>> Agreed.
>>>>
>>>>
>>>
>>>
>>
>
>

Received on Friday, 25 July 2008 12:54:18 UTC