Re: An approach to xsd:dateTime

On Jul 25, 2008, at 8:55 AM, Uli Sattler wrote:

>
> 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?!

Hi Uli,

I think this will almost certainly be wrong if owl-standard-time-zone- 
time is any specific time zone. The statement Breakfast is at 7AM  
(unfortunately) doesn't mean 7 AM owl-standard-time-zone-time. It  
means local time, wherever local is.

If we are making a commitment to a specific timezone for times without  
timezones, the supporting timezones in constants is trivial - an  
addition or subtraction.
In that case we could, instead of committing to a single owl-standard- 
time-zone-time, make owl-standard-time-zone-time be the local time  
zone, with the determination of local being up to the implementation.

-Alan


>
>
> 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 15:53:49 UTC