Re: [Tzdist] Existing and new data ...

Lester Caine <lester@lsces.co.uk> Wed, 10 December 2014 18:35 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 626481A1A07 for <tzdist@ietfa.amsl.com>; Wed, 10 Dec 2014 10:35:38 -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 ZkJqW9o1s_jQ for <tzdist@ietfa.amsl.com>; Wed, 10 Dec 2014 10:35:36 -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 26E311A1B21 for <tzdist@ietf.org>; Wed, 10 Dec 2014 10:35:30 -0800 (PST)
Received: (qmail 27905 invoked by uid 89); 10 Dec 2014 18:35:28 -0000
Received: by simscan 1.3.1 ppid: 27899, pid: 27902, t: 0.0851s 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 18:35:28 -0000
Message-ID: <54889270.7040801@lsces.co.uk>
Date: Wed, 10 Dec 2014 18:35:28 +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: tzdist@ietf.org
References: <54888642.1030108@lsces.co.uk> <F2F4FB8F282334E543F462B5@caldav.corp.apple.com>
In-Reply-To: <F2F4FB8F282334E543F462B5@caldav.corp.apple.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tzdist/Y9qu7Aw4NR_RHNhcuJrg7bFIRPY
Subject: Re: [Tzdist] Existing and new 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 18:35:38 -0000

On 10/12/14 17:58, Cyrus Daboo wrote:
> I have not come across a single client to date that will detect a change
> to time zone data and warn users about possible shifts to meeting times
> as a result of that. They simply can't figure that out as the underlying
> TZ data typically is coming from the OS and there is no version
> information readily available.

This is perhaps the point. The current mechanism is so badly broken we
can't even establish just where the source TZ material came from. THAT
is why I started digging since not only was historic material corrupted
due to the lack of tagging as to how it was created, but also current
data was being corrupted by using essentially broken versions of TZ data.

We need to CREATE a process that can be relied on to provide TZ data to
go with ANYTHING we publish from day one, and that requires a version.
That same version then allows client applications ... if they can be
bothered .. to check the integrity of what they are displaying. Perhaps
only certain clients will use the process, but a reliable process IS
necessary. This then simply expands over time to provide reliable
reference material for historic archives, and that may well be todays
calendars of events which while one might expect the data to be the same
in many years time, simply being able to access a perfectly matched
extract for the TZid and period of the material may be important if the
tzdist publisher is 'only' producing a truncated view for the then
current period.

My own rude awakening to this was when all the scheduled council
meetings moved an hour on the diary when the DST rolled over because the
person who had 'improved' the calendar code at that time did not even
understand what DST was :( Just because software gets it wrong is not a
reason for continuing to live with the problem?

-- 
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