On 2014-08-28 08:10 AM, Poul-Henning Kamp wrote:
--------
In message <alpine.lsu.2.00.1408281021260.23...@hermes-1.csi.cam.ac.uk>, Tony F
inch writes:
However for events in the future (meetings etc.) you
need to record a time and a place, because the UTC offset and time zone
rules are not predictable.
The main problem here is to get people to give you enough information
in the first place.
For instance:
I add a meeting to my calendar at 10:00 day after tomorrow.
Tomorrow I fly to Ulan Batoor.
When is the meeting ?
It could be a meeting in Ulan Batoor, it could be a phone-meeting
back in Denmark or it could be a teleconference with Melbourne.
Many heuristic attempts have been made to "DWIM" and all fails.
8601 is not even attempting to get anywhere near that problem,
all it tries to do, is ensure that when I write a timestamp
with some number of components, you will read it the same way
and get the same components with the same numerical values.
But 8601 doesn't care or try to make sense of what the numbers might mean.
An organization I work with has been using a web-based meeting
scheduling calendar that gives meeting date-time notifications.
Recently it has been announcing meetings as, for example -
"When: Wednesday, September 24, 2014 11:00 AM-12:30 PM. (UTC-05:00)
Eastern Time (US & Canada)"
Of course Daylight is in effect on the east coast, so its completely
wrong. What is intended is 2014-09-24T12:00-04:00 (noon, "Eastern
Daylight Time").
Ironic that a web site serving a working group concerned with
timekeeping gets this go badly confused.
It would better if 8601 provided a DST flag, so you might have something
like 2014-09-24T12:00-05:00S1, where "-05:00" is the fixed offset from
UTC for the locality, and "S1" means "(Daylight) *S*avings in effect".
-Brooks
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
