[tz] 2013g - Morocco
eggert at cs.ucla.edu
Thu Oct 3 02:00:27 UTC 2013
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
* 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
@@ -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
@@ -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):
-# 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-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
More information about the tz