[tz] 2013g - Morocco

[Paul Eggert]

yoshito_umaoka at us.ibm.com wrote:

> I'm actually not 100% sure if we can still use the tz database for year 
> 2038 and beyond, or if the tz database has no support / desire for make it 
> work beyond 2038.

We do want to support far-future dates, but unfortunately there's
currently no way to represent rules based on calendars other than
the Gregorian calendar.  Currently we list these rules by hand,
year by year, cutting the rules off after 32-bit signed time_t
values roll over, since we can't go on *forever*, and platforms
with 32-bit signed time_t don't benefit from entries after the rollover.

> I would like to ask the tz database coordinators to select rule line more 
> friendly for users using the database for 2038 and beyond.

Yes, that makes sense.  The problem you noticed was not something I
anticipated or thought of; sorry about that.

How about the following fix?  It should result in better predictions
after 2038 than simply cutting off after 2037.  I've pushed this into
the experimental github version.


>From 2ecfc39ab6ca9712afdfbd507e2215ed0d584cc3 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert at cs.ucla.edu>
Date: Wed, 2 Oct 2013 18:43:31 -0700
Subject: [PATCH] Fix problem with Morocco time stamps after 2037.

Problem reported by Yoshito Umaoka in
<http://mm.icann.org/pipermail/tz/2013-October/020423.html>.
* africa (Morocco): Stop after 2038, not 2037.
* NEWS: Document this.
---
 NEWS   |  6 ++++++
 africa | 17 ++++++++++++-----
 2 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/NEWS b/NEWS
index 8e9518c..58f8126 100644
--- a/NEWS
+++ b/NEWS
@@ -2,6 +2,12 @@ News for the tz database
 
 Unreleased, experimental changes
 
+  Changes affecting future time stamps:
+
+    Add entries for DST transitions in Morocco in the year 2038.
+    This avoids some year-2038 glitches introduced in 2013g.
+    (Thanks to Yoshito Umaoka for reporting the problem.)
+
   Changes affecting the build procedure
 
     The builder can specify which programs to use, if any, instead of
diff --git a/africa b/africa
index 20b00eb..415330c 100644
--- a/africa
+++ b/africa
@@ -868,13 +868,13 @@ Zone	Indian/Mayotte	3:00:56 -	LMT	1911 Jul	# Mamoutzou
 # Another source (specifying the time for start and end in the decree):
 # http://www.lemag.ma/Heure-d-ete-au-Maroc-jusqu-au-27-octobre_a75620.html
 
-# From Paul Eggert (2013-09-30):
+# From Paul Eggert (2013-10-02):
 # To estimate what the Moroccan government will do in future years,
 # transition dates for 2014 through 2037 were determined by running
 # the following program under GNU Emacs 24.3:
 #
 # (let ((islamic-year 1435))
-#   (while (< islamic-year 1460)
+#   (while (< islamic-year 1461)
 #     (let ((a
 #	     (calendar-gregorian-from-absolute
 #	      (calendar-islamic-to-absolute (list 9 1 islamic-year))))
@@ -894,9 +894,13 @@ Zone	Indian/Mayotte	3:00:56 -	LMT	1911 Jul	# Mamoutzou
 # all transitions removed for 2026-2035, where the estimated Ramadan
 # falls entirely outside daylight-saving time; and with fall-back
 # transitions removed for 2036-2037, where the normal fall-back
-# date falls during the estimated Ramadan.  Problems continue after that,
-# but 32-bit time_t values roll around in 2038 so for now do not worry
-# about dates after 2037.
+# date falls during the estimated Ramadan.  Normally, the table would
+# stop after 2037 because 32-bit time_t values roll around early in 2038,
+# but that would imply a prediction of perpetual DST after March 2038
+# due to the year-2037 glitches.  So, this table instead stops after
+# 2038, the first non-glitchy year after the 32-bit rollover.
+# An advantage of stopping after 2038 is that it lets zic guess
+# TZ='WET0WEST,M3.5.0,M10.5.0/3' for time stamps far in the future.
 
 # RULE	NAME	FROM	TO	TYPE	IN	ON	AT	SAVE	LETTER/S
 
@@ -955,6 +959,9 @@ Rule	Morocco	2025	only	-	Mar	 31	 2:00	1:00	S
 Rule	Morocco	2026	max	-	Mar	 lastSun 2:00	1:00	S
 Rule	Morocco	2036	only	-	Oct	 21	 3:00	0	-
 Rule	Morocco	2037	only	-	Oct	 11	 3:00	0	-
+Rule	Morocco	2038	only	-	Sep	 30	 3:00	0	-
+Rule	Morocco	2038	only	-	Oct	 30	 2:00	1:00	S
+Rule	Morocco	2038	max	-	Oct	 lastSun 3:00	0	-
 
 # Zone	NAME		GMTOFF	RULES	FORMAT	[UNTIL]
 Zone Africa/Casablanca	-0:30:20 -	LMT	1913 Oct 26
-- 
1.8.1.2