Re: An approach to xsd:dateTime

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.

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:34:36 UTC