IETF Logo Mail Archive

Re: [Tzdist] [tz] Timezone in Brazil

Paul Eggert <eggert@cs.ucla.edu> Sun, 11 October 2015 23:40 UTC

Return-Path: <eggert@cs.ucla.edu>
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 343821B2EF3 for <tzdist@ietfa.amsl.com>; Sun, 11 Oct 2015 16:40:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 hEouuJcCcnSI for <tzdist@ietfa.amsl.com>; Sun, 11 Oct 2015 16:40:41 -0700 (PDT)
Received: from zimbra.cs.ucla.edu (zimbra.cs.ucla.edu [131.179.128.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D29A51B2EF2 for <tzdist@ietf.org>; Sun, 11 Oct 2015 16:40:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 94C38160E14; Sun, 11 Oct 2015 16:40:41 -0700 (PDT)
Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id CZuXiZTBy7Sp; Sun, 11 Oct 2015 16:40:40 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id DCB24160E16; Sun, 11 Oct 2015 16:40:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu
Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 5I1Jx2yNLG8t; Sun, 11 Oct 2015 16:40:40 -0700 (PDT)
Received: from [192.168.1.9] (pool-100-32-155-148.lsanca.fios.verizon.net [100.32.155.148]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id BF4A8160E14; Sun, 11 Oct 2015 16:40:40 -0700 (PDT)
To: lester@lsces.co.uk
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> <c2c676b8-4b37-4677-9283-36d263a05acf.maildroid@localhost>
From: Paul Eggert <eggert@cs.ucla.edu>
Organization: UCLA Computer Science Department
Message-ID: <561AF378.2080904@cs.ucla.edu>
Date: Sun, 11 Oct 2015 16:40:40 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <c2c676b8-4b37-4677-9283-36d263a05acf.maildroid@localhost>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tzdist/A1omYL09TgTRLppk5YU-5lQcEXw>
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:40:43 -0000

lester@lsces.co.uk wrote:
> 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.

If backzone is used to build the tzdist server's data, then the server contains 
more data, some good and some questionable.  Some of the good data is before 
1970, and some after.  Some of the questionable data is before 1970, and some 
after.  In this sense, it's just the same as when backzone is not used.  So 
there's no good reason to require implementations to reject time stamps before 
1970 merely because backzone is being used (or is not being used).

I get the sense that you're trying to shoehorn backzone into a slot that it's 
not designed for.  It appears that you want some indication of how reliable data 
are.  There is no such indication anywhere in the formal part of tzdata, nor in 
tzdist, and this is true regardless of whether backzone is used.

v2.23.0 | Report a Bug | By Email