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

Tim Parenti <> Fri, 13 November 2015 19:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1EAE31B302E for <>; Fri, 13 Nov 2015 11:07:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.498
X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZgRNQBJwtAhp for <>; Fri, 13 Nov 2015 11:06:58 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B3F9E1B302C for <>; Fri, 13 Nov 2015 11:06:58 -0800 (PST)
Received: by igbxm8 with SMTP id xm8so20429739igb.1 for <>; Fri, 13 Nov 2015 11:06:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CY6PkkFbUA4IVUogEaKjepJ7D3dLR79g1lkkzYaGnBg=; b=ht6xW0GAaX12vB0lIqmGpg+gWAIwFqDkMZYynJJ1ry2O3yV5XRinVknKL3HwOiybXy OWxEhE418l7bSgruOpT83MycqiaTra0h/t5m5xpttQYbcu0GeCi26UpqxJ0E/xbIVWbR Fys9Bv6q1QcMUfbLioZR8jmQ/oQsUCA83gMVhg7ZV7KCx95ikSIQSfOok0nF6lMutCrG CO/y2mOtsLyjHRDTl5K6zBNaYv7qu0HlVcdoF5zcyIx6zzfvo67X2K0pAguLVh0WjgEA 6Sd+BNZrPReie8MAyABlOq/B+ddMbuvfwcACKGYsAmvqYWMv40gkAbbHmQEqYVrsk5Bn 4z1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CY6PkkFbUA4IVUogEaKjepJ7D3dLR79g1lkkzYaGnBg=; b=EgJXDhNx/BpnSvEj5iw1LX4hJ4diyDIScGEMb7X8URiC1Dv1cdHazZAgp9kIE7Y7uL WJvpOHSUzohv8i8qKpcXcbS7VesP2KiSgTcshbITSpMrsl30mm4Wv8my1wc+NYeAMqym WH+4o1FhGA+qQbiALG7hCXwaZoQzlFGrTmcbYHycdWa+rYh3MQxjCjkjzX3Wx+XcnTF6 CG4jM+xCSUSjSaEHUKpJf5Xbq8L8e05rXAgbdV7klsyoKfpcRsGAeEySllZFemCwSFE2 xIhotIUP/71fiRXLluKZLxjaZi0m/PV2ZuBCRtY010wIDW9IRxx1tL7OR1g63DglidEu IApQ==
X-Gm-Message-State: ALoCoQm1hIAw2RSQSBmaYNOMb/Xv6lUUo0bK/QgI6bjELH//yFvWwt5v8+6wL8FlE7UCUlaBHyRN
X-Received: by with SMTP id eh9mr4226612igb.46.1447441617966; Fri, 13 Nov 2015 11:06:57 -0800 (PST)
Received: from ( []) by with ESMTPSA id kb7sm1815772igb.11.2015. for <> (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 Nov 2015 11:06:56 -0800 (PST)
Received: by ioc74 with SMTP id 74so106765947ioc.2 for <>; Fri, 13 Nov 2015 11:06:56 -0800 (PST)
MIME-Version: 1.0
X-Received: by with SMTP id c138mr11490504ioc.15.1447441616475; Fri, 13 Nov 2015 11:06:56 -0800 (PST)
Received: by with HTTP; Fri, 13 Nov 2015 11:06:56 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Fri, 13 Nov 2015 14:06:56 -0500
X-Gmail-Original-Message-ID: <>
Message-ID: <>
From: Tim Parenti <>
To: Ken Murchison <>
Content-Type: multipart/alternative; boundary=001a114093f4621dec052470c3ec
Archived-At: <>
Cc: Time Zone Data Distribution Service <>
Subject: Re: [Tzdist] Fun with tzdata and non-Gregorian DST rules
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 13 Nov 2015 19:07:00 -0000

On 13 November 2015 at 13:50, Ken Murchison <>; wrote:

> I found this interesting/amusing so I thought I'd share it.


I briefly looked for other zones based on lunisolar calendars and didn't
> come up with any.  The Brazilian rules are essentially based around Easter
> and there is no way that I have found to represent Easter as a recurrence
> rule in iCalendar.
> All of this is just for fun at this point because I don't believe that any
> calendaring clients have support for RSCALE yet.

I've been thinking on similar things for a while... currently tz only
bothers with transitions within the 32-bit POSIX timestamp range, even
though it's technically 64-bit capable.  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, in order to be able to compactly represent
transitions N years in the future for any reasonable N.

The toughest parts will be dealing with places where the rules are based on
a mixture of calendaring systems, such as Africa/Cairo.

Tim Parenti