Re: An approach to xsd:dateTime

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.
>>
>>
>
>