[Fwd: Re: STMML units and date/time values]

[Scott Chapal]

Peter Murray-Rust <pm286 at cam.ac.uk> writes:

> At 09:43 24/10/2002 -0800, Matt Jones wrote:

> [There is nothing above that says the quantity must be a scalar nor
> that it must be real. A complex number could have a magnitude on some
> measurement scale an a phases angle on another. I can talk of a
> diffracted Xray as having a magnitude of 50 electrons and a phase
> angle of 1.2 radians. Neither is valid without the other. This isn't
> the current problem but it shows that some concepts are not easy to
> represent.]
> 
> 
> > Applying these rules to dates, one might talk about a "datetime"
> > quantity such as "the amount of time elapsed since the beginning of
> > the Gregorian Calendar" (or since 1960 if you're a SAS user :) which

> There is a difference between a point on a measurement scale and the
> difference between two points. Thus 0deg C = 273.15 K but kJ/K is the
> same as kJ/C

Conventions and scales are applied to suit the needs (or whims) of the
user.

SAS was developed from mainframe PL/1 and chose January 1, 1960 as the
midpoint for its date[time] range.

The EPOCH is defined as January 1, 1970 on UNIX systems.

These conventions were instituted to facilitate calculations, and they
represent (arbitrary) points on a scale.

> > gigaseconds (Gs), which is 10^9 seconds.  There have been about 6.31
> > Gs since the year of our Lord.

The gregorian calendar counts from the year 0 (or is that 1?), and
that's the current commonly accepted scale.

> > Of course, we don't represent seconds in such even quantities as
> > that, and instead use things like minutes, hours, days, months,
> > years, centuries, millenia, and eons!  To complicate things, these
> > traditional time periods are not constant through time (e.g., this
> > month contains a different number of seconds than last month).
> > Thus, we have a complicated thing we called a calendar system that
> > tells us, for any given period, how many seconds were or will be
> > contained in that period.

Not to mention leapyears!

> > So, theoretically at least, gregorian years and gigaseconds are
> > interconvertible by using a calendar.
> 
> Agreed. But it is critical to know what the conversion is.
> 
> >As a datetime value is an elapsed time value
> 
> I may be wrong but I think that "datetime" ISO 8601 is for absolute
> times;

Is Einstein smiling, or what?

> W3C use "duration"  for differences. The STMML usage of
> datetime and duration is defined to be that required by the W3C XML
> Schema specification.

The distinction of datetime and duration (elapsed time) is at the
heart of this confusion, I think.

> This is a logical explanation of the process. Actual implementations
> are free to optimize as long as they produce the same results.

So the fact that SAS uses 1960 is irrelevant, but practical.

> > The calendar *is* the conversion formula between gregorian units and
> > SI seconds.

> I don't think there are gregorian units... I think the W3 Schemas
> shows how to extract SI seconds from two gregorian datetimes.

Right, differences between datetimes have units.

> dataType is used in the sense of W3C Schema. It includes things like
> URLs, strings, etc. which have no units and are not quantities.

> > This is because we have a small set of common dataTypes for a given
> > language or system for pragmatic and not theoretical reasons.  Some
> > database theoreticians (e.g., C.J. Date) have argued strongly that

Lemme guess: Christian Julian Date? :)

> > existing database systems are messed up because they don't allow you
> > to model the domain precisely, and instead just give you a limited
> > set of "data types" as surrogates for the domain.

> > If a scientist uses an event recorder to
> > timestamp events (such as datetime values every time a cell
> > divides), it would be nice to know what units are used so that
> > mathematical calculations and comparisons can be made with those
> > values.

This is elapsed time (duration), counted in seconds.

> The fact that SAS stores datetime values in seconds highlights even
> more strongly that

> 1) datetime values are quantities, and

> 2) those quantities have units (in SAS, they use SI seconds as the unit).

To me, this illustrates that SAS (or any date arithmetic) requires
representation of datetimes in values with constant units so that
calculations can be made.

> STMML offers the approaches:
> (a) use SI seconds, minutes and hours FOR DURATIONS. Everything else
> requires careful definition (day. month, year...)
> 
> (b) use XSD durations for durations. This is precise in the XSD
> document = you just have to have software that processes it
> 
> (c) use XSD/ISO8601 for datetimes (for actual dates and times). This
> is almost universally regarded as the best way

> If you have metersPerSecond - no problem. If you have metersPerYear,
> YOU have to say what a year is :-)

Thanks for the thoughtful discussion.

-- 
Scott E. Chapal_________________________________________________
Database & Network Manager             scott.chapal at jonesctr.org
J.W. Jones Ecological Research Center          229.734.4706 x227
Rt. 2. Box. 2324. Newton, GA 31770-9651        229.734.6650 :FAX