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

Lester Caine <lester@lsces.co.uk> Wed, 10 December 2014 21:53 UTC

Return-Path: <lester@lsces.co.uk>
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 523A41A9080 for <tzdist@ietfa.amsl.com>; Wed, 10 Dec 2014 13:53:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 mQY6bN_tCKTV for <tzdist@ietfa.amsl.com>; Wed, 10 Dec 2014 13:53:53 -0800 (PST)
Received: from mail4.serversure.net (mail4-2.serversure.net [217.147.176.214]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12C8F1A90AE for <tzdist@ietf.org>; Wed, 10 Dec 2014 13:53:47 -0800 (PST)
Received: (qmail 15489 invoked by uid 89); 10 Dec 2014 21:53:46 -0000
Received: by simscan 1.3.1 ppid: 15483, pid: 15486, t: 0.0848s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677
Received: from unknown (HELO ?10.0.0.8?) (lester@rainbowdigitalmedia.org.uk@86.178.188.220) by mail4.serversure.net with ESMTPA; 10 Dec 2014 21:53:46 -0000
Message-ID: <5488C0EA.8090505@lsces.co.uk>
Date: Wed, 10 Dec 2014 21:53:46 +0000
From: Lester Caine <lester@lsces.co.uk>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Time Zone Data Distribution Service <tzdist@ietf.org>
References: <059.5da79d7c9d394e20e3c22513cfe04c33@tools.ietf.org> <5475BD47.7040900@lsces.co.uk> <CADZyTkmviNBkM-C_-5Gq+RruUu7R7P9bwKCvg7+1nGnx+NzJ_Q@mail.gmail.com> <54788334.3010604@lsces.co.uk> <CADZyTkn92ZXnf0MOJjFH59eAYG_Bnu5FZ0x1UcoUq27MkRKZzA@mail.gmail.com> <5479E42A.8080306@lsces.co.uk> <CADZyTk=aVNFmoR1GA+w_xU7+-28Rnb-TJY4uT-jVOU4jdC1yKg@mail.gmail.com> <CACzrW9D=wZi1VvCiGa-4kwbKAyHMs6rduF6+cKA0Nn0gshm+sQ@mail.gmail.com> <54877E06.5020409@lsces.co.uk> <39981BA759F3923868CCFBD3@caldav.corp.apple.com> <54888249.9080607@lsces.co.uk> <CAFpi07z8NauUZ5aBqqg9sXDsmSA+hG4HuZNDkLe7fnk=mg4wgA@mail.gmail.com> <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>
In-Reply-To: <CADC+-gTiyJ4QHZT6m3je9M9-ifSELnSWgmgy7iXSWNS+p8pthg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tzdist/lU9cAxEGFz801dpBo2ivAWe6L2U
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: Wed, 10 Dec 2014 21:53:55 -0000

On 10/12/14 20:38, Doug Royer wrote:
> The organizer of an event specifies the timezone info. Even if it does
> not match yours, its the time they will be hosting the event.
> 
> Why does it have to match another event from another organizer?
If they are organising linked meetings such as video conferencing then
it would be useful if they are using the same set of offsets?

I can keep adding examples of where a change to the local time of a
meeting may impinge on other activities in different time zones. Booking
flights is another problem if you have allowed an hour to get your
flight and the meeting is moved back an hour ...

If all you need is the local time then you probably have no interest in
UTC anyway which is why most systems could not even handle an event
which happens across several time zones. It's putting the system in
place that ensures that when booking a multi timezone event everybody is
using the same set of offsets.

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk