Keith Moore wrote:
However, many events are actually specified relative to a particular
timezone, and timezone offsets occasionally change with little advance
warning. As such, this representation may not be sufficient for
specifying dates and times of some kinds of events, particularly
future events.
This is correct. The IMPP group covered this in Minneapolis, I think. The
draft alludes to the problem, but may not be explicit enough (probably
isn't, if Keith felt it necessary to comment):
o All times expressed have a stated relationship (offset) to
Coordinated Universal Time (UTC). (This is distinct from some
usage in scheduling applications where a local time and location
may be known, but the actual relationship to UTC may be dependent
on the unknown or unknowable actions of politicians or
administrators. The UTC time corresponding to 17:00 on 23rd March
2005 in New York may depend on administrative decisions about
daylight savings time. This specification steers well clear of
such considerations.)
I believe that Keith is right, that this paragraph should include a
reference to iCalendar (RFC-2445) and point readers to that for use when a
simple timestamp won't do. It's a small point, but it could prevent some
confusion.
/========================================================\
|John Stracke |Principal Engineer |
|jstracke(_at_)incentivesystems(_dot_)com |Incentive Systems, Inc.|
|http://www.incentivesystems.com |My opinions are my own.|
|========================================================|
|"Time is money, and price is information." --Russ Nelson|
\========================================================/