RE: An approach to xsd:dateTime

Hello,

Having only one time line (without the time zone) is rather usual in programming languages. For example, this is how java.util.Date
works: it is internally implemented to store the number of milliseconds elapsed from January 1, 1970, 00:00:00 GMT. This value is
always in GMT.

When you want to put this value onto the Gregorian calendar, then you need to specify a time zone, and you get back an the 8-tuple
(day, month, year, hour, minute, second, millisecond, time zone). You are also free to use calendars other than the Gregorian.

Windows Win32 API works in a similar way and, if my memory serves me right, UNIX has something similar as well.

Form an implementor's perspective, such a design is beneficial because reasoning with dates is really easy: it is the same as with
owl:number. The only complicated machinery is in reading the constants and converting them into the number of milliseconds.

Regards,

	Boris

> -----Original Message-----
> From: Alan Ruttenberg [mailto:alanruttenberg@gmail.com]
> Sent: 24 July 2008 06:09
> To: Boris Motik
> Cc: 'Michael Smith'; public-owl-wg@w3.org
> Subject: Re: An approach to xsd:dateTime
> 
> 
> On Jul 23, 2008, at 6:14 PM, Boris Motik wrote:
> 
> >
> > Hello,
> >
> > The problem seems a bit more complicated. What do you do with the
> > time zone if it is present on some constant?
> This is well defined in http://www.w3.org/TR/xmlschema11-2/#vp-dt-timeOnTimeline
> 
> The issue is really what to do about constants without time zone, as
> these don't have a specific location on the time line.
> Or they have a position on a different time line (depends on your
> point of view)
> 
> > Another way forward would be to make the value space of dateTime the
> > (continuous) time line at Greenwich. Each number on the time
> > line would correspond to the number of seconds elapsed from some
> > fixed point, such as the beginning of AD or something similar. (I
> > am deliberately not using UTC -- I'll explain shortly.) In this way,
> > you have a unique time point for every event, and that time
> > point is not dependent on the time zone or on effects such as
> > daylight saving. Furthermore, the value space is isomorphic to
> > owl:number, which makes reasoning simpler.
> 
> This is effectively TimeOnTimeline. owl:number is a reasonable value
> space because the value space is otherwise decimal, and owl:number is
> what we use for decimal.
> 
> > Time zone, daylight saving, and leap seconds would be relevant only
> > for dateTime constants. For example, you might have a constant
> > "midnight on 1/1/2008 in London", and this constant would be mapped
> > to the same time point as the constant "1am on 1/1/2008 in
> > Berlin". Thus, the time zone, leap seconds, and daylight saving
> > would be relevant only when you want to refer to actual time points.
> >
> > Now I deliberately didn't want to say that the value space of
> > dateTime should be UTC because UTC time consists of a day, month,
> > year, hour, minute, and second. As such, it is not just one number,
> > but six numbers, which makes reasoning more complicated.
> > Furthermore, a minute in UTC can contain leap seconds, which is yet
> > another complication for reasoning.
> 
> The leap seconds is a separate issue, I think. The main issue is that
> leap seconds are defined only historically. So no matter what you
> can't account for them completely. In any case, the latest version of
> the spec explicitly says that it doesn't handle leap seconds.
> http://www.w3.org/TR/xmlschema11-2/#d-t-values
> 
> > I believe that such a design would work. The main problem, however,
> > is that we don't have (or at least I don't know of) a standard
> > that we can point to and that we could reuse. Specifying something
> > like this from scratch might require a lot of work; furthermore,
> > I don't believe that this is the core competence of our WG.
> 
> I don't think we are designing from scratch - the XML Schema provides
> us what is needed to map to owl:number.
> 
> The biggest decision is what to do about the TZ specified versus TZ
> not specified values. If  each (with/without)  were placed on separate
> timelines, then the only thing we would lose is the ability to use a
> facet value of one kind with the value space of the other, unless
> someone has an idea of how to do something reasonable with areas where
> the two are incomparable (when they are with 24 hours of each,
> ignoring time zone).
> 
> -Alan
> 
> >
> > Regards,
> >
> > 	Boris
> >
> >> -----Original Message-----
> >> From: public-owl-wg-request@w3.org [mailto:public-owl-wg-request@w3.org
> >> ] On Behalf Of Michael Smith
> >> Sent: 23 July 2008 17:33
> >> To: public-owl-wg
> >> Subject: Re: An approach to xsd:dateTime
> >>
> >>
> >> On Wed, 2008-07-23 at 14:49 -0400, Michael Smith wrote:
> >>> As I read the XML Schema 1.1 description of dateTime [1], the
> >>> primary
> >>> problem it presents as a datatype is that timezone is optional.
> >>> If OWL
> >>> were to require the timezone property, all values map to a single
> >>> point
> >>> on a discrete number line (see [2]), making implementation
> >>> equivalent to
> >>> implementation of xsd:integer.
> >>
> >> Tracker, this was in reference to ISSUE-126.
> >> --
> >> Mike Smith
> >>
> >> Clark & Parsia
> >>
> >
> >
> >

Received on Thursday, 24 July 2008 10:58:13 UTC