Re: An approach to xsd:dateTime

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.

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 11:45:56 UTC