Re: [Tzdist] Fun with tzdata and non-Gregorian DST rules

Paul Eggert <eggert@cs.ucla.edu> Sat, 14 November 2015 06:00 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 E17151AC3F9 for <tzdist@ietfa.amsl.com>; Fri, 13 Nov 2015 22:00:27 -0800 (PST)
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 1fvuvya-iIKt for <tzdist@ietfa.amsl.com>; Fri, 13 Nov 2015 22:00:26 -0800 (PST)
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 8B6AB1B39AB for <tzdist@ietf.org>; Fri, 13 Nov 2015 22:00:26 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 578FA160D75; Fri, 13 Nov 2015 22:00:26 -0800 (PST)
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 rtkts1-a84pu; Fri, 13 Nov 2015 22:00:19 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 762D0160DFA; Fri, 13 Nov 2015 22:00:19 -0800 (PST)
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 zLW0H00oL_Zy; Fri, 13 Nov 2015 22:00:19 -0800 (PST)
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 4DDAD160D75; Fri, 13 Nov 2015 22:00:19 -0800 (PST)
To: Tim Parenti <tim@timtimeonline.com>, Ken Murchison <murch@andrew.cmu.edu>
References: <5646310E.8050503@andrew.cmu.edu> <CAFpi07xDumE+E33mzzBmKq4JWiAQWjm2zMR8OHEsWf_qjd=2yg@mail.gmail.com>
From: Paul Eggert <eggert@cs.ucla.edu>
Organization: UCLA Computer Science Department
Message-ID: <5646CDEF.40507@cs.ucla.edu>
Date: Fri, 13 Nov 2015 22:00:15 -0800
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: <CAFpi07xDumE+E33mzzBmKq4JWiAQWjm2zMR8OHEsWf_qjd=2yg@mail.gmail.com>
Content-Type: multipart/mixed; boundary="------------030400010001040908070301"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tzdist/bBJF5JDKhFs71298GKwfrdLZMV4>
Cc: Time Zone Data Distribution Service <tzdist@ietf.org>
Subject: Re: [Tzdist] Fun with tzdata and non-Gregorian DST rules
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: Sat, 14 Nov 2015 06:00:28 -0000

Tim Parenti wrote:
> When it comes time for tz to start
> caring about transitions beyond 2038 (which I'd argue is sooner than
> later!), we may need to take a hard look at natively supporting other
> calendaring systems like RSCALE

Officially time in Iran is astronomical, not arithmetic; so although 
RSCALE-based predictions are more accurate than tz's Gregorian-only rules can 
be, even RSCALE is bound to be wrong at some point. Oscar van Vlijmen's comment 
in the 'asia' file suggests that 2058 is the first problematic year.

As a practical matter it may not help that much to support RSCALE, as the 
Iranian government is likely to change the rules before 2038 anyway.

Come to think of it, the tz entry for Iran can do a better job than it does now; 
proposed patch attached.