is America/Chicago a daml-time time standard, or just CDT/CST?

Hi,

I have been working on an RDF schema for iCalendar data
for several years now; I have tried several different
designs for modelling time zones, and I'm not quite comfortable
with any of them.

This week I re-discovered the DAML time work; in particular,
this bit...

[[
We have been refering to time _zones_, but in fact it is more
convenient to work in terms of what we might call the "time standard"
that is used in a time zone.  That is, it is better to work with *PST*
as a legal entity than with the *PST* zone as a geographical region.
A time standard is a way of computing the time, relative to a
world-wide system of computing time.  For each time standard, there is
a zone, or geographical region, and a time of the year in which it is
used for describing local times.  Where and when a time standard is
used have to be axiomatized, and this involves interrelating a time
ontology and a geographical ontology.  These relations can be quite
complex.  Only the entities like *PST* and *EDT*, the time standards,
are part of the _time_ ontology.
]]
--                     A DAML Ontology of Time
                             Jerry R. Hobbs
                             November 2002
http://www.cs.rochester.edu/~ferguson/daml/daml-time-nov2002.txt


My question is: does "Chicago time", which changes between CST and
CDT, fit this notion of time standard?

The reason I ask is...

I maintain some timezone data in RDF...
  http://www.w3.org/2002/12/cal/#tzd


And there is renewed interest in a timezone registry...

"TC-TIMEZONE was formed as a result of work being done in CalDAV showing
the need for a formal time zone registry"
 -- Report on Roundtable II/Interop II -- 11-13 January 2005
  http://www.calconnect.org/roundtable2.html


The calconnect folks are working on iCalendar, an
IETF Proposed Standard. The iCalendar specification
for Timezones is
  http://www.w3.org/2002/12/cal/rfc2445#sec4.6.5


The RDF data I maintain are derived from an iCalendar formatted
version of the tzinfo database that governs timezone calculations
on lots of computers...

"The public-domain time zone database contains code and data that
represent the history of local time for many representative locations
around the globe. ... This database (often called tz or zoneinfo) is
used by several implementations, including the GNUC Library used in
GNU/Linux, FreeBSD, NetBSD, OpenBSD, Cygwin ..."
  -- http://www.twinsun.com/tz/tz-link.htm

The sources of that database are filled with fascinating trivia
about timezone laws and such. The brilliant compromise they
use is...

  Each location in the database represents a national region
  where all clocks keeping local time have agreed since 1970.

Interestingly, both daml-time and this page about the tzinfo
database note the special case of Indiana...

  Locations are identified by continent or ocean and then by the name
  of the location, which is typically the largest city within the
  region. For example, America/New_York represents most of the
  US eastern time zone; America/Indianapolis represents most of
  Indiana, which uses eastern time without daylight saving
  time (DST) ...

The location in the database that corresponds to where
I live is called "America/Chicago".

Here's a turtle/n3 syntax view of (the gist of) the
RDF view of America/Chicago, i.e.
  http://www.w3.org/2002/12/cal/tzd/America/Chicago

    Chi:tz     a :Vtimezone;
         x:licLocation "America/Chicago";
         :daylight  [
             :dtstart  [
                 :dateTime "1970-04-05T02:00:00" ];
             :rrule  [
                 :byday "1SU";
                 :bymonth "4";
                 :freq "YEARLY";
                 :interval "1" ];
             :tzname "CDT";
             :tzoffsetfrom "-0600";
             :tzoffsetto "-0500" ];
         :standard  [
             :dtstart  [
                 :dateTime "1970-10-25T02:00:00" ];
             :rrule  [
                 :byday "-1SU";
                 :bymonth "10";
                 :freq "YEARLY";
                 :interval "1" ];
             :tzname "CST";
             :tzoffsetfrom "-0500";
             :tzoffsetto "-0600" ];
         :tzid "/softwarestudio.org/Olson_20011030_5/America/Chicago" .


The question is whether Chicago:tz fits the daml-time notion
of time standard.

Here's some example data from my itinerary for my next trip,
to show how we use Chi:tz as a property to relate times to strings...
  http://www.w3.org/2005/03dc-bos/bos-tp-aa

    bo:_g0     a :Vevent,
         k:fromLocation <http://www.daml.org/cgi-bin/airport?MCI>;
         k:toLocation <http://www.daml.org/cgi-bin/airport?ORD>;
         t:arrivalTime "16:27";
         t:departureTime "15:00";
         t:flightNumber "1094";
         :dtend  [
             Chi:tz "2005-02-26T16:27:00" ];
         :dtstart  [
             Chi:tz "2005-02-26T15:00:00" ];
         :summary "#1094 to ORD on AMERICAN AIRLINES" .


The itinerary data is generated from a recent design,
but the timezone data were generated from an older design.
I'm not sure if they line up... I hope to re-generate
the timezone data to be sure.

I think I prefer to treat timezones as RDF datatypes, ala...

    bo:_g0     a :Vevent,
         :dtend  "2005-02-26T16:27:00"^^Chi:tz.

For those familiar with logic but who have not been dragged thru
RDF datatypes, they're pretty much like function terms:

  dtend(g0, Chi:tz("2005-02-26T16:27:00"))

hmmm... maybe I have that backwards... maybe it's

  (E x) dtend(g0, x) & Chi:tz(x) = "2005-02-26T16:27:00"

Which reminds me...

I'm also looking at re-generating the timezone RDF data or perhaps
just changing the iCalendar/RDF schema in order to accommodate
a recent request from TimBL to be more explicit about some
constraints in order to support a diff/sync architecture we're
working on...

 Please put IFP and FP decls into the TZD and iCal ontologies
 http://lists.w3.org/Archives/Public/www-rdf-calendar/2005Feb/0002.html

He's basically asking to add

  ical:Vtimezone rdfs:subClassOf owl:InverseFunctionalProperty.

to the iCalendar schema, and I'm thinking about whether
that makes sense. Tim and I were talking about what
happens at 2am on Sundays in the spring and fall and
whether we need some sort of "if a local time maps
to 2 UTC times, pick the first one" rule to avoid
an inconsistency.

I'm trying to absorb the dam-time ontology by transcribing
it to N3 so that I can actually use it with my data
and schemas...
  http://www.w3.org/2000/10/swap/util/time.n3
  v 1.1 2005/02/18 03:05:12

I have only worked thru a few sections so far; I'm not sure
when I'll get down to the timezone section. So I thought
I'd bundle up what I learned so far and send this question,
in case I don't get back to it on my own.


-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Friday, 18 February 2005 15:22:27 UTC