[LEAPSECS] Leap second relationship to ISO 8601

[Brooks Harris]

On 2014-08-28 08:10 AM, Poul-Henning Kamp wrote:
> --------
> In message <alpine.LSU.2.00.1408281021260.23119 at 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