More tweaks on time related datatypes and minor editorial

This is somewhat related to George Joseph's previous post.

1) First, my interpretation of this statement:

   Time periods, i.e. specific durations of time, can be represented by
supplying two items of information:
   a start instant and a duration or a start instant and an end instant or
an end instant and a duration.

Is that a time period, could be represented by the combination of two
attributes (or two element content) where one is a timeInstant and the other
a timeDuration or timeInstant, for example:

<quietPeriod start="1999-11-05T12:00:00Z" end="1999-12-17T00:00:00Z"/>
or
<quitePeriod start="1999-11-05T12:00:00Z" duration="1M12D"/>

George's interpretation is this is an allowance for ISO8601's time period
formats such as

<quietPeriod start="1999-11-05T12:00:00Z/1999-12-17T00:00:00Z"/>

I believe that my interpretation is consistent with the preceding discussion
of the lexical representation, but please clarify for George and possibly
make the quoted paragraph less ambiguous.

2) Comparisons of timeDurations

As discussed in previous messages, evaluation of min and max constraints on
timeDuration can be problematic since the month and year terms are imprecise
(months being between 28-31 days and years being 365 or 366 days).  Based on
a suggestion George made on the Xerces list (and attributed to the ISO 8601
spec, but I can't find any mention of it). I would recommend that for
evaluation of min and max constraints on timeDurations (and only for that
comparision) that fixed unambiguous durations be specified for year and
date.  Somebody can check my math, but for a 400 year cycle, the average
length of a year is 31556952 seconds.  One twelveth (a month) of this is
2629746 seconds.  These values would result in P1Y == P12M, P366D > P1Y >
P365D, P31D > P1M > P30D.  I think this is reasonable behavior and resolves
a sticky issue.  However, the recommendation must explicitly describe how
this comparision should be performed.


3) Elimination of time zone offsets on timeInstant and time types.

Currently, timeInstant and time allow either a 'Z' to indicate Universal
Coordinated Time or a time zone offset from UTC in the format
('+'|'-')hh:mm.  It substantially complicates comparsion of times when the
times have different time zone offsets.  When the time zone offset are the
same, comparisions can be made lexically.  The time zone offset is either a
hint at the time zone of some action or observer or an attempt to make the
format more presentable to someone reading the XML file.  If the first, then
that information should be made explicit.  If the second, then that violates
the spirit of XML to keep data and presentation separate and does so at the
cost of complexity and possibly performance degradation.

My suggestion is that only Z be supported for timeInstant and time.  This
would allow these types to lexically compared.  If a time zone offset for a
display or a particular location needs to be specified, it could be
specified with an additional attribute (or element) with a timeDuration
datatype.

<Flight number="1234" departCode="IAH" departTime="14:23:00Z"
departTimezone="-PT6H" arriveCode="DTW" arriveTime="16:54:00Z"
arriveTimezone="-PT5H"/>


dates would still need to allow a time zone qualifier.  I would suggest that
the time zone qualifer be ignored in the evaluation of min and max
constraints on dates.

Received on Saturday, 22 January 2000 01:18:30 UTC