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

From: Ken Murchison <[email-masked]>
Date: Fri, 13 Nov 2015 13:50:54 -0500

All,

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

I was poking around tzdata trying to figure out why Asia/Tehran compiled 
with vzic doesn't include a POSIX tz string and I found out that its 
because the Iranian DST rules are based on the Persian calendar, not the 
Gregorian calendar.  This is why the Rule for Iran has a list of changes 
in groups of 1-3 years up to 2038 and no Rule that extends out into the 
future.

As can be expected, an iCalendar representation for Asia/Tehran based on 
tzdata also has a list of dates and no recurrence rule that repeats forever.

However, a much more compact iCalendar representation for this zone that 
does extend to eternity can be created using Non-Gregoran Recurrence 
Rules in iCalendar <https://tools.ietf.org/html/rfc7529> (RSCALE).

I created a new zone named Asia/Tehran_Persian using the RSCALE 
extension and installed it on my tzdist test server.

For those that are interested, you can look at the 2 zones here:

https://cyrus-test.andrew.cmu.edu/tzdist/zones/Asia/Tehran
https://cyrus-test.andrew.cmu.edu/tzdist/zones/Asia/Tehran_Persian

If you want to compare the observances, especially those from 1991-2038 
(yes, they match), you can view them here in JSON format:

https://cyrus-test.andrew.cmu.edu/tzdist/zones/Asia/Tehran/observances?start=0000-01-01T00:00:00Z&end=2500-01-01T00:00:00Z
https://cyrus-test.andrew.cmu.edu/tzdist/zones/Asia/Tehran_Persian/observances?start=0000-01-01T00:00:00Z&end=2500-01-01T00:00:00Z

and here in "zdump -V" format:

https://cyrus-test.andrew.cmu.edu/tzdist/zones/Asia/Tehran/observances?start=0000-01-01T00:00:00Z&end=2500-01-01T00:00:00Z&format=application/zdump
https://cyrus-test.andrew.cmu.edu/tzdist/zones/Asia/Tehran_Persian/observances?start=0000-01-01T00:00:00Z&end=2500-01-01T00:00:00Z&format=application/zdump

For those that are really ambitious, you can look at a binary "tzfile" 
version of Asia/Tehran_Persian (which gets created from the iCalendar 
data) here:

https://cyrus-test.andrew.cmu.edu/tzdist/zones/Asia/Tehran_Persian?format=application/tzfile

This file is binary compatible with one created by vzic except I don't 
add a transition at 2440-01-01 like vzic does.  (I'm not even sure why 
that transition is there or what it means).

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.

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

---

From: Tim Parenti <[email-masked]>
Date: Fri, 13 Nov 2015 14:06:56 -0500

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

Cool!

> 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

---

From: Jonathan Lennox <[email-masked]>
Date: Fri, 13 Nov 2015 14:41:49 -0500

On Friday, November 13 2015, "Ken Murchison" wrote to "Time Zone Data Distribution Service" saying:

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

Between 2005 and 2012, Israeli daylight savings time (Asia/Jerusalem) ended
on the Hebrew calendar, which is lunisolar: the rule was that DST ended on
the Saturday before Yom Kippur (the 10th of Tishrei).  (It started on the
Gregorian calendar, on the Friday before April 2nd.)

The law was changed in 2013, but this still seems like something you could
try modeling with RSCALE, either for the historical period or for a
proleptic version of the 2005 rules.

-- 
Jonathan Lennox
[email-masked]

---

From: Ken Murchison <[email-masked]>
Date: Fri, 13 Nov 2015 20:58:57 -0500

> proleptic version of the 2005 rules.

https://cyrus-test.andrew.cmu.edu/tzdist/zones/Asia/Jerusalem_Hebrew

The rule for end of DST for 2005-1012 is this:

BEGIN:STANDARD
TZNAME:IST
TZOFFSETFROM:+0300
TZOFFSETTO:+0200
DTSTART:20051009T020000
RRULE:FREQ=YEARLY;RSCALE=HEBREW;BYMONTH=1;BYMONTHDAY=3,4,5,6,7,8,9;BYDAY=SU;UNTIL=20120923T010000Z
END:STANDARD

Its also looks like 6 of the 8 transitions from 2001 to 2004 are based 
on a fixed date on the Hebrew calendar: 16 Nisan and 7 Tishrei

---

From: Paul Eggert <[email-masked]>
Date: Fri, 13 Nov 2015 22:00:15 -0800

Tim Parenti wrote:
> When it comes time for tz to start
> 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.
>From 67d3a13549e629cc5d0579ac68ad3e2783e44582 Mon Sep 17 00:00:00 2001
From: Paul Eggert <[email-masked]>
Date: Fri, 13 Nov 2015 21:56:25 -0800
Subject: [PROPOSED PATCH] Improve guesses for post-2037 Iran

* NEWS: Document this.
* asia (Iran): Predict 2038 and later DST to be March 21 thru Sept. 21.
This is not correct, but it's better than predicting no DST.
---
 NEWS |  6 ++++++
 asia | 11 +++++++++--
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/NEWS b/NEWS
index b4e1483..121e0e4 100644
--- a/NEWS
+++ b/NEWS
@@ -11,6 +11,12 @@ Unreleased, experimental changes
     America/Metlakatla switched from PST all year to AKST/AKDT on
     2015-11-01 at 02:00.  (Thanks to Steffen Thorsen.)
 
+  Changes affecting future time stamps
+
+    Asia/Tehran now has DST predictions for the year 2038 and later,
+    to be March 21 00:00 to September 21 00:00.  This is likely better
+    than predicting no DST, albeit off by a day every now and then.
+
   Changes affecting documentation
 
     tz-link.htm mentions the BDE library (thanks to Andrew Paprocki).
diff --git a/asia b/asia
index 5467024..f170244 100644
--- a/asia
+++ b/asia
@@ -1084,8 +1084,15 @@ Rule	Iran	2032	2033	-	Mar	21	0:00	1:00	D
 Rule	Iran	2032	2033	-	Sep	21	0:00	0	S
 Rule	Iran	2034	2035	-	Mar	22	0:00	1:00	D
 Rule	Iran	2034	2035	-	Sep	22	0:00	0	S
-Rule	Iran	2036	2037	-	Mar	21	0:00	1:00	D
-Rule	Iran	2036	2037	-	Sep	21	0:00	0	S
+#
+# The following rules are approximations starting in the year 2038.
+# These are the best post-2037 approximations available, given the
+# restrictions of a single rule using a Gregorian-based data format.
+# At some point this table will need to be extended, though quite
+# possibly Iran will change the rules first.
+Rule	Iran	2036	max	-	Mar	21	0:00	1:00	D
+Rule	Iran	2036	max	-	Sep	21	0:00	0	S
+
 # Zone	NAME		GMTOFF	RULES	FORMAT	[UNTIL]
 Zone	Asia/Tehran	3:25:44	-	LMT	1916
 			3:25:44	-	TMT	1946     # Tehran Mean Time
-- 
2.5.0