Re: [Tzdist] [tz] Timezone in Brazil

lester@lsces.co.uk Sun, 11 October 2015 23:08 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 5DEDF1B2EBE for <tzdist@ietfa.amsl.com>; Sun, 11 Oct 2015 16:08:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level:
X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, 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 11leB_gkt70N for <tzdist@ietfa.amsl.com>; Sun, 11 Oct 2015 16:08:25 -0700 (PDT)
Received: from mail4.serversure.net (mail4.serversure.net [217.147.176.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CB611B2EBD for <tzdist@ietf.org>; Sun, 11 Oct 2015 16:08:24 -0700 (PDT)
Received: (qmail 6419 invoked by uid 89); 11 Oct 2015 23:08:22 -0000
Received: by simscan 1.3.1 ppid: 6411, pid: 6416, t: 0.1275s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677
Received: from unknown (HELO miab022) (lester@rainbowdigitalmedia.org.uk@81.138.11.136) by mail4.serversure.net with ESMTPA; 11 Oct 2015 23:08:22 -0000
Date: Mon, 12 Oct 2015 00:08:20 +0100
From: lester@lsces.co.uk
To: Paul Eggert <eggert@cs.ucla.edu>
Message-ID: <c2c676b8-4b37-4677-9283-36d263a05acf.maildroid@localhost>
In-Reply-To: <561AE1A8.50209@cs.ucla.edu>
References: <5A4DF0AAB9712D44A68CEB0278F6ED5A2549ADA9F7@AICEXMBXCL02.LGE.NET> <FAD2916B-8E7A-49F5-A0EE-B173A3104531@mac.com> <BLU185-W6869D5866CF2840EE88B90C2340@phx.gbl> <5A4DF0AAB9712D44A68CEB0278F6ED5A2549ADB0B5@AICEXMBXCL02.LGE.NET> <BLU185-W46E73842162C12C34B0F9CC2340@phx.gbl> <87zizruzd1.fsf@fastmail.com> <F1FFEEB5-B0C0-422B-A159-3448950D448C@alum.mit.edu> <561A4544.5000308@lsces.co.uk> <B553BC64-36B2-4463-B490-D3A96648365F@alum.mit.edu> <561AC26A.6040006@lsces.co.uk> <561AD0C0.9090406@cs.ucla.edu> <561ADC8E.2070201@lsces.co.uk> <561AE1A8.50209@cs.ucla.edu>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_0_528473112.1444604900846"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tzdist/550jHPfVviLYm3qzvrEPvaDvAYI>
Cc: Time Zone Data Distribution Service <tzdist@ietf.org>
Subject: Re: [Tzdist] [tz] Timezone in Brazil
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: <https://mailarchive.ietf.org/arch/browse/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: Sun, 11 Oct 2015 23:08:27 -0000

But you are always gambling that the client machine has actually compiled WITH backzone? If it is missing then data prior to 1970 is suspect.

Sent from my android device so quoting is crap ... need to kill these painful email clients!

-----Original Message-----
From: Paul Eggert <eggert@cs.ucla.edu>
To: Lester Caine <lester@lsces.co.uk>
Cc: Time Zone Data Distribution Service <tzdist@ietf.org>
Sent: Sun, 11 Oct 2015 23:24
Subject: Re: [tz] Timezone in Brazil

>>> tzdb should only be published with a
>>> 1970 start date and anything prior to that is unreliable

>> >No, many tzdata entries before 1970 are quite reliable.  True, tzdata
>> >entries tend to become less reliable the further back one goes in time,
>> >but this is merely a tendency.  For example, the data for England in
>> >1915 is far more reliable than the data for Baja California state in 2015.

> 'MANY' ... but there is data in backzone

Sure, but backzone is published as part of tzdata, and it's easy to use; just 
set a switch in the Makefile.  And regardless of whether backzone is used, 
there's no good reason to require implementations to reject time stamps before 1970.