Re: [Tzdist] Fwd: [tzdist] #32 (service): managing historical data

Martin Burnicki <martin.burnicki@burnicki.net> Fri, 12 December 2014 10:24 UTC

Return-Path: <martin.burnicki@burnicki.net>
X-Original-To: tzdist@ietfa.amsl.com
Delivered-To: tzdist@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688291ACCC7 for <tzdist@ietfa.amsl.com>; Fri, 12 Dec 2014 02:24:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level:
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pa6Gv_AT3Bo for <tzdist@ietfa.amsl.com>; Fri, 12 Dec 2014 02:24:22 -0800 (PST)
Received: from www52.your-server.de (www52.your-server.de [213.133.104.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65B321ACC91 for <tzdist@ietf.org>; Fri, 12 Dec 2014 02:24:22 -0800 (PST)
Received: from [88.198.220.131] (helo=sslproxy02.your-server.de) by www52.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from <martin.burnicki@burnicki.net>) id 1XzNOW-0002gS-6X for tzdist@ietf.org; Fri, 12 Dec 2014 11:24:20 +0100
Received: from [217.6.112.194] (helo=[172.16.102.127]) by sslproxy02.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from <martin.burnicki@burnicki.net>) id 1XzNOS-0006vz-T3 for tzdist@ietf.org; Fri, 12 Dec 2014 11:24:16 +0100
Message-ID: <548AC24D.1040407@burnicki.net>
Date: Fri, 12 Dec 2014 11:24:13 +0100
From: Martin Burnicki <martin.burnicki@burnicki.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:34.0) Gecko/20100101 Firefox/34.0 SeaMonkey/2.31
MIME-Version: 1.0
To: tzdist@ietf.org
References: <059.5da79d7c9d394e20e3c22513cfe04c33@tools.ietf.org> <676B23282D9F7F1DCE6A54C7@caldav.corp.apple.com> <CAFpi07x79gJLEBWmpxWv7V13CiwmeKGy7bwS1=+ukp-sKmwFxA@mail.gmail.com> <5488921B.8020900@lsces.co.uk> <5488973F.7050400@andrew.cmu.edu> <54889C39.1080103@lsces.co.uk> <D2BE5C3BFE11019ECF4BEF62@caldav.corp.apple.com> <5488A6E6.8050903@lsces.co.uk> <CADC+-gTiyJ4QHZT6m3je9M9-ifSELnSWgmgy7iXSWNS+p8pthg@mail.gmail.com> <5488C0EA.8090505@lsces.co.uk> <CADC+-gTgckSe1ca6Sai6RguQid=ReM7bH6K8+dVVFm-YfbpFbA@mail.gmail.com> <5488DA56.2090306@lsces.co.uk> <CADC+-gQN=Qb2y8M-bHnPzMcK8r=xUG-seQ7XzvZwwcWsHpHnBQ@mail.gmail.com> <54895986.6060806@lsces.co.uk> <5489CA90.1070307@gmail.com> <35BC5886C9A58F866E8A46A8@caldav.corp.apple.com> <5489D9F7.3080207@gmail.com> <D196D63077FEC1B090DF7C86@caldav.corp.apple.com> <5489F79E.4080909@gmail.com> <BC19CC6916DC0E59CA63737D@caldav.corp.apple.com> <548A17A9.5040608@gmail.com> <548A6C5B.7030804@gmail.com>
In-Reply-To: <548A6C5B.7030804@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Authenticated-Sender: mailout@burnicki.net
X-Virus-Scanned: Clear (ClamAV 0.98.4/19769/Fri Dec 12 06:48:46 2014)
Archived-At: http://mailarchive.ietf.org/arch/msg/tzdist/ypAJlutX7rRYbvWTcvPxE3fzl_k
Subject: Re: [Tzdist] Fwd: [tzdist] #32 (service): managing historical data
X-BeenThere: tzdist@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <tzdist.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tzdist>, <mailto:tzdist-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tzdist/>
List-Post: <mailto:tzdist@ietf.org>
List-Help: <mailto:tzdist-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tzdist>, <mailto:tzdist-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Dec 2014 10:24:24 -0000

Mike Douglass wrote:
> We managed to get away with it in the US because the rules changed so
> infrequently. Also there were many fewer centralized calendar services.
>
> By providing an easily accessible and frequently updated timezone source
> hopefully we can reduce the errors.

I absolutely agree, and I'm trying to summarize some cases.

Maybe we should look at a number of different cases which should be 
handled greatfully. Let's assume an appointment is to be made in 
Morocco, or Egypt, where we have seen that decisions about start or end 
of DST can be published only 3 days before this actually happens.

A local event is planned for a specific local time. If the DST rules 
change before the event actually happens the organizer (the person) has 
to decide whether the UTC start time should be kept the same, and thus 
the local start time should change, or if the local start time should be 
kept unchanged and thus the UTC start time changes.

In my opinion the usual case would be to keep the local start time 
unchanged to keep the relative time (e.g. "after lunch").

For international events basically the same facts apply. If the TZ rule 
changes for the organizer, the organizer has to decide whether he would 
keep his local time, and thus all other participant in different time 
zones had to change or update their start times, given in local time 
according to their selected time zone, or if the organizer prefers to 
keep the "international" time and thus nothing changes for the 
international participants.

Obviously the decision whether to change the UTC start time or the local 
time depends on the organizer.

If the organizer is an airline and the event is a flight then I'd expect 
the UTC start time is kept unchanged.

If it's a phone conference if may depend on the how attentive the 
organizer is. If he's  the boss and the other ones are employees he may 
insist on keeping his local time. If the participants are like partners 
he might want to reduce the overall effort, keep the international start 
time and adjust only his local time.

If you are going to go to the cinema in the country where the TZ rule 
changes then surely the local time when the film starts will be kept the 
same, even if the TZ rules change.

So obviously there is one point which can't be handled by a protocol 
like tzdist, i.e., which decision is made by the organizer.

On the other hand, regardless which decision is made by the organizer, 
the tzdist protocol should be able to help getting this handled as 
smoothly as possible in each of these cases.

Personally I would find it most helpful if I (my smartphone, or my PC) 
receive a notification if something in the time zone I've selected 
changes. Hoewever, of course this is not part of the protocol but of the 
client implementation.

Martin