a new dateTime/timezone design, with datatypes

Summary: my discomfort with our timezone design motivated
me to implement a new one. Who likes it? Who dislikes it?

Details:

My wearable gizmo has an XMLRPC interface that expects
times in Z-time. My itineraries are given to me
in airport-local time. So I need to reason about the
relationship between this format:

         cal:dtstart  [
             cal:dateTime "2004-04-20T12:24:00";
             cal:tzid
"/softwarestudio.org/Olson_20011030_5/America/Chicago" ];

and this format:

  <start_date>20040617T210000Z</start_date>

The tzid property doesn't give me the information I need;
it's valid, if somewhat perverse, to use the string "America/Chicago"
as a reference to a timezone declaration for New York time.

Actually, I learned just today that...
   The presence of the SOLIDUS character (US-ASCII decimal 47) as a
   prefix, indicates that this TZID represents a unique ID in a globally
   defined time zone registry (when such registry is defined).
  -- http://www.w3.org/2002/12/cal/rfc2445#sec4.2.19

So "/softwarestudio.org/Olson_20011030_5/America/Chicago" does
give me enough information to do the conversion, strictly speaking.
But peeking into the string is messy.


Recall our discussion...

 RDF calendar agenda item G: InterpretationProperties, esp as applied to
timezones
 posted by libby at 2003-09-10 15:52 (+)
 http://rdfig.xmlhack.com/2003/09/10/2003-09-10.html#1063209175.159585

 RESOLVED:To note the issue with InterpretationProperties as discussed 
 last time, but to keep the status quo

Well, I'm increasingly dissatisfied by the status quo. TimBL's
recent message got me thinking about it...

[[[
Solution:    instead of
	 timething   :tzid "whatver";
write
	 timething   :timezone  [ :tzid "whatver" ]

where timezone is FP and tzid is IFP.
]]]
 -- http://lists.w3.org/Archives/Public/www-rdf-calendar/2004Mar/0016.html

I was noodling on designs like that and
mortenf suggested I go even further and write:

	event dtstart "2004..."^^timezone.

After coding it up, I like it. There are three cases:
(1) Z-time (2) timezone (3) floating.

case (1) goes from
 DTSTAMP:20020630T230600Z
to
 <dtstamp rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime"
   >2002-06-30T23:06:00Z</dtstamp>

i.e. in case (1), I'm using the XML Schema dateTime datatype

case (2) goes from...
 DTSTART;
  TZID=/softwarestudio.org/Olson_20011030_5/America/New_York:20030108T130000
to...
 <dtstart
   rdf:datatype="http://www.w3.org/2002/12/cal/tzd/America/New_York#tz"
    >2003-01-08T13:00:00</dtstart>

and case (3) goes from
 DTSTART:19701025T020000
to ...
 <dtstart
            rdf:parseType="Resource"
      ><dateTime>1970-10-25T02:00:00</dateTime>
 </dtstart>

i.e. in the floating-time case, I use an ical:dateTime property and a string; no datatype.

I went so far as to commit
  http://www.w3.org/2002/12/cal/fromIcal.py Revision 2.15  2004/04/14 21:31:26
  http://www.w3.org/2002/12/cal/fromIcalTest.py v 1.7 2004/04/14 21:32:51
and I committed lots of cal/test/*.rdf updates.

I haven't updated toIcal.py yet, and I haven't finished my localtime->Z-time
conversion use case yet. I intend to let you know when I do.



-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
see you at the WWW2004 in NY 17-22 May?

Received on Wednesday, 14 April 2004 18:03:29 UTC