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

Lester Caine <lester@lsces.co.uk> Thu, 11 December 2014 21:07 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 8CEF41A8033 for <tzdist@ietfa.amsl.com>; Thu, 11 Dec 2014 13:07:14 -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 fJGydoYp2j6Q for <tzdist@ietfa.amsl.com>; Thu, 11 Dec 2014 13:07:13 -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 289A91A1A22 for <tzdist@ietf.org>; Thu, 11 Dec 2014 13:07:12 -0800 (PST)
Received: (qmail 29916 invoked by uid 89); 11 Dec 2014 21:07:10 -0000
Received: by simscan 1.3.1 ppid: 29910, pid: 29913, t: 0.0980s 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; 11 Dec 2014 21:07:10 -0000
Message-ID: <548A077E.1010806@lsces.co.uk>
Date: Thu, 11 Dec 2014 21:07:10 +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: <059.5da79d7c9d394e20e3c22513cfe04c33@tools.ietf.org> <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> <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> <5489E233.9080504@lsces.co.uk> <5489FC59.2040203@gmail.com>
In-Reply-To: <5489FC59.2040203@gmail.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tzdist/XhLIleC8kxY2-yKc8nzcGup6M9U
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: Thu, 11 Dec 2014 21:07:14 -0000

On 11/12/14 20:19, Doug Royer wrote:
>> Calendaring systems still do not cover cross timezone activities well,
>> and I don't think iCalendar is particularly friendly in solving the
>> problems that need to be handled? For genealogical data we often flag
>> a time range covering the uncertainty in when an event happened so
>> that when time lining events one can see if something could have been
>> concurrent which can then can be researched in further detail. While
>> planning new events where a site may have a variation of local offset
>> it would be useful that the tzdist data actually flagged that there is
>> uncertainty in a forthcoming event if only to allow an organiser to
>> block bookings on that day or period. Often the organisers have no
>> understanding that these events may happen, so in addition to cleanly
>> publishing a short notice change, publishing a potential race problem
>> is an equally valid objective? 
> 
> Is that not what BUSY-TENTATIVE is used for?
> Or maybe PARTSTAT=TENTATIVE or STATUS=TENTATIVE ?
> It would have to be up to the CUA/user/organizer to decide if they want
> to book one of those times.

I don't use iCalendar which is why I would prefer a clean TZ dataset
rather than one that is processed to what I still view as a non-standard
format for other calendaring systems. So I'm looking at the information
being transferred rather than a single usage. So I'd welcome any input
on just how some of these things could be presented.

> As to TZ data, are you saying 'it may have been this time range' with
> respect to past time zone entries?
For the historic material that is currently relegated to backzone that
may well be the case, but for current data TZ publishes the 'best guess'
for the next transition on many TZid's and the notes advise what event
may change that guess. I've covered this some time back in that we could
add comments to an offset to indicate that a transition may change at
short notice. Currently there is no mechanism in TZ to flag that there
are two potential values for a period but it is something that at the
calendaring level would be useful to display.

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