Morocco not ending DST tonight - instead extending by one month
Morocco extends DST by one month, on very short notice, just 1 day before it was going to end. There is a new decree (2.13.781) for this, where DST from now on goes from last Sunday of March at 02:00 to last Sunday of October at 03:00, similar to EU rules. Official source (French): http://www.maroc.gov.ma/fr/actualites/lhoraire-dete-gmt1-maintenu-jusquau-27... 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 Our brief summary in English: http://www.timeanddate.com/news/time/morocco-ends-dst-2013.html Best regards, Steffen Thorsen - timeanddate.com
Thanks, here's a proposed patch to implement this, which I've pushed to the experimental version on github. I'd like to release a new version very soon, since the tz database is currently incorrect for Morocco. (I wish they'd give more notice!)
From 0def5ed0fd67bf3093a69a5659537a3a32ee1d4e Mon Sep 17 00:00:00 2001 From: Paul Eggert <eggert@cs.ucla.edu> Date: Sun, 29 Sep 2013 21:30:30 -0700 Subject: [PATCH] Morocco changed end-of-DST from September to October.
* africa (Morocco): Morocco now ends DST the last Sunday in October, not September. (Thanks to Steffen Thorsen.) * NEWS: Document the above. --- NEWS | 5 +++++ africa | 13 ++++++++++++- 2 files changed, 17 insertions(+), 1 deletion(-) diff --git a/NEWS b/NEWS index 14f75fa..5a8d8fc 100644 --- a/NEWS +++ b/NEWS @@ -3,6 +3,11 @@ News for the tz database Unreleased, experimental changes + Changes affecting current and near-future time stamps + + Morocco changed their rules, and now falls back the first Sunday + in October, not September. (Thanks to Steffen Thorsen.) + Changes affecting 'zic' 'zic' now runs on platforms that lack both hard links and symlinks. diff --git a/africa b/africa index 9a5d93b..d168597 100644 --- a/africa +++ b/africa @@ -858,6 +858,16 @@ Zone Indian/Mayotte 3:00:56 - LMT 1911 Jul # Mamoutzou # transitions would be 2013-07-07 and 2013-08-10; see: # http://www.maroc.ma/en/news/morocco-suspends-daylight-saving-time-july-7-aug... +# From Steffen Thorsen (2013-09-28): +# Morocco extends DST by one month, on very short notice, just 1 day +# before it was going to end. There is a new decree (2.13.781) for +# this, where DST from now on goes from last Sunday of March at 02:00 +# to last Sunday of October at 03:00, similar to EU rules. Official +# source (French): +# http://www.maroc.gov.ma/fr/actualites/lhoraire-dete-gmt1-maintenu-jusquau-27... +# 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-07-03): # To estimate what the Moroccan government will do in future years, # transition dates for 2014 through 2021 were determined by running @@ -913,11 +923,12 @@ Rule Morocco 2010 only - Aug 8 0:00 0 - Rule Morocco 2011 only - Apr 3 0:00 1:00 S Rule Morocco 2011 only - Jul 31 0 0 - Rule Morocco 2012 2019 - Apr lastSun 2:00 1:00 S -Rule Morocco 2012 max - Sep lastSun 3:00 0 - +Rule Morocco 2012 only - Sep 30 3:00 0 - Rule Morocco 2012 only - Jul 20 3:00 0 - Rule Morocco 2012 only - Aug 20 2:00 1:00 S Rule Morocco 2013 only - Jul 7 3:00 0 - Rule Morocco 2013 only - Aug 10 2:00 1:00 S +Rule Morocco 2013 max - Oct lastSun 3:00 0 - Rule Morocco 2014 only - Jun 29 3:00 0 - Rule Morocco 2014 only - Jul 29 2:00 1:00 S Rule Morocco 2015 only - Jun 18 3:00 0 - -- 1.8.1.2
Come to think of it, my previously-proposed patch can't be right for 2036 and 2037. as the predicted dates for Ramadan in those years overlap the new fall-back dates. Here's a revised patch that takes this into account; this matters only for time stamps after 2035. As a result of this change, Africa/Casablanca becomes the only Zone for which zic cannot generate a POSIX environment variable (for time stamps past 2038). I've pushed this revised edition to the experimental version on github. diff --git a/NEWS b/NEWS index 14f75fa..c89e339 100644 --- a/NEWS +++ b/NEWS @@ -3,6 +3,11 @@ News for the tz database Unreleased, experimental changes + Changes affecting current and near-future time stamps + + Morocco changed their rules, and now falls back the first Sunday + in October, not September. (Thanks to Steffen Thorsen.) + Changes affecting 'zic' 'zic' now runs on platforms that lack both hard links and symlinks. diff --git a/africa b/africa index 9a5d93b..16fe153 100644 --- a/africa +++ b/africa @@ -858,13 +858,23 @@ Zone Indian/Mayotte 3:00:56 - LMT 1911 Jul # Mamoutzou # transitions would be 2013-07-07 and 2013-08-10; see: # http://www.maroc.ma/en/news/morocco-suspends-daylight-saving-time-july-7-aug... -# From Paul Eggert (2013-07-03): +# From Steffen Thorsen (2013-09-28): +# Morocco extends DST by one month, on very short notice, just 1 day +# before it was going to end. There is a new decree (2.13.781) for +# this, where DST from now on goes from last Sunday of March at 02:00 +# to last Sunday of October at 03:00, similar to EU rules. Official +# source (French): +# http://www.maroc.gov.ma/fr/actualites/lhoraire-dete-gmt1-maintenu-jusquau-27... +# 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-29): # To estimate what the Moroccan government will do in future years, -# transition dates for 2014 through 2021 were determined by running +# 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 1444) +# (while (< islamic-year 1460) # (let ((a # (calendar-gregorian-from-absolute # (calendar-islamic-to-absolute (list 9 1 islamic-year)))) @@ -880,12 +890,12 @@ Zone Indian/Mayotte 3:00:56 - LMT 1911 Jul # Mamoutzou # (setq islamic-year (+ 1 islamic-year)))) # # with the results hand-edited for 2020-2022, when the normal spring-forward -# date falls during the estimated Ramadan. -# -# From 2023 through 2038 Ramadan is not predicted to overlap with -# daylight saving time. Starting in 2039 there will be overlap again, +# date falls during the estimated Ramadan; with results removed for 2023-2035, +# where the estimated Ramadan falls entirely outside daylight-saving time, +# and the results hand-edited again 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 2038. +# about dates after 2037. # RULE NAME FROM TO TYPE IN ON AT SAVE LETTER/S @@ -913,11 +923,12 @@ Rule Morocco 2010 only - Aug 8 0:00 0 - Rule Morocco 2011 only - Apr 3 0:00 1:00 S Rule Morocco 2011 only - Jul 31 0 0 - Rule Morocco 2012 2019 - Apr lastSun 2:00 1:00 S -Rule Morocco 2012 max - Sep lastSun 3:00 0 - +Rule Morocco 2012 only - Sep 30 3:00 0 - Rule Morocco 2012 only - Jul 20 3:00 0 - Rule Morocco 2012 only - Aug 20 2:00 1:00 S Rule Morocco 2013 only - Jul 7 3:00 0 - Rule Morocco 2013 only - Aug 10 2:00 1:00 S +Rule Morocco 2013 2035 - Oct lastSun 3:00 0 - Rule Morocco 2014 only - Jun 29 3:00 0 - Rule Morocco 2014 only - Jul 29 2:00 1:00 S Rule Morocco 2015 only - Jun 18 3:00 0 - @@ -934,6 +945,8 @@ Rule Morocco 2020 only - May 24 2:00 1:00 S Rule Morocco 2021 only - May 13 2:00 1:00 S Rule Morocco 2022 only - May 3 2:00 1:00 S Rule Morocco 2023 max - Apr lastSun 2:00 1:00 S +Rule Morocco 2036 only - Oct 21 3:00 0 - +Rule Morocco 2037 only - Oct 11 3:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Casablanca -0:30:20 - LMT 1913 Oct 26
Hello, Please note too that the Moroccan government has change too the date to the beginning of DST at the last sunday of March (April before). Source: http://www.mmsp.gov.ma/fr/actualites.aspx?id=395 == French == [...] Le décret en question établit d'ailleurs que dorénavant, on avancera d'une heure nos montres par rapport à l'heure de Greenwich (GMT) à la fin de chaque mois de mars et on retournera à " l'heure d'hiver " à la fin de chaque mois d'octobre. == English translation via google == [...] The Decree also establishes that now, an hour we advance our watches over Greenwich Mean Time (GMT) at the end of each March and "winter time" we will return to at the end of every October. Milamber Le 30/09/2013 05:56, Paul Eggert a ecrit :
Come to think of it, my previously-proposed patch can't be right for 2036 and 2037. as the predicted dates for Ramadan in those years overlap the new fall-back dates. Here's a revised patch that takes this into account; this matters only for time stamps after 2035.
As a result of this change, Africa/Casablanca becomes the only Zone for which zic cannot generate a POSIX environment variable (for time stamps past 2038).
I've pushed this revised edition to the experimental version on github.
diff --git a/NEWS b/NEWS index 14f75fa..c89e339 100644 --- a/NEWS +++ b/NEWS @@ -3,6 +3,11 @@ News for the tz database
Unreleased, experimental changes
+ Changes affecting current and near-future time stamps + + Morocco changed their rules, and now falls back the first Sunday + in October, not September. (Thanks to Steffen Thorsen.) + Changes affecting 'zic'
'zic' now runs on platforms that lack both hard links and symlinks. diff --git a/africa b/africa index 9a5d93b..16fe153 100644 --- a/africa +++ b/africa @@ -858,13 +858,23 @@ Zone Indian/Mayotte 3:00:56 - LMT 1911 Jul # Mamoutzou # transitions would be 2013-07-07 and 2013-08-10; see: # http://www.maroc.ma/en/news/morocco-suspends-daylight-saving-time-july-7-aug...
-# From Paul Eggert (2013-07-03): +# From Steffen Thorsen (2013-09-28): +# Morocco extends DST by one month, on very short notice, just 1 day +# before it was going to end. There is a new decree (2.13.781) for +# this, where DST from now on goes from last Sunday of March at 02:00 +# to last Sunday of October at 03:00, similar to EU rules. Official +# source (French): +# http://www.maroc.gov.ma/fr/actualites/lhoraire-dete-gmt1-maintenu-jusquau-27... +# 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-29): # To estimate what the Moroccan government will do in future years, -# transition dates for 2014 through 2021 were determined by running +# 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 1444) +# (while (< islamic-year 1460) # (let ((a # (calendar-gregorian-from-absolute # (calendar-islamic-to-absolute (list 9 1 islamic-year)))) @@ -880,12 +890,12 @@ Zone Indian/Mayotte 3:00:56 - LMT 1911 Jul # Mamoutzou # (setq islamic-year (+ 1 islamic-year)))) # # with the results hand-edited for 2020-2022, when the normal spring-forward -# date falls during the estimated Ramadan. -# -# From 2023 through 2038 Ramadan is not predicted to overlap with -# daylight saving time. Starting in 2039 there will be overlap again, +# date falls during the estimated Ramadan; with results removed for 2023-2035, +# where the estimated Ramadan falls entirely outside daylight-saving time, +# and the results hand-edited again 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 2038. +# about dates after 2037.
# RULE NAME FROM TO TYPE IN ON AT SAVE LETTER/S
@@ -913,11 +923,12 @@ Rule Morocco 2010 only - Aug 8 0:00 0 - Rule Morocco 2011 only - Apr 3 0:00 1:00 S Rule Morocco 2011 only - Jul 31 0 0 - Rule Morocco 2012 2019 - Apr lastSun 2:00 1:00 S -Rule Morocco 2012 max - Sep lastSun 3:00 0 - +Rule Morocco 2012 only - Sep 30 3:00 0 - Rule Morocco 2012 only - Jul 20 3:00 0 - Rule Morocco 2012 only - Aug 20 2:00 1:00 S Rule Morocco 2013 only - Jul 7 3:00 0 - Rule Morocco 2013 only - Aug 10 2:00 1:00 S +Rule Morocco 2013 2035 - Oct lastSun 3:00 0 - Rule Morocco 2014 only - Jun 29 3:00 0 - Rule Morocco 2014 only - Jul 29 2:00 1:00 S Rule Morocco 2015 only - Jun 18 3:00 0 - @@ -934,6 +945,8 @@ Rule Morocco 2020 only - May 24 2:00 1:00 S Rule Morocco 2021 only - May 13 2:00 1:00 S Rule Morocco 2022 only - May 3 2:00 1:00 S Rule Morocco 2023 max - Apr lastSun 2:00 1:00 S +Rule Morocco 2036 only - Oct 21 3:00 0 - +Rule Morocco 2037 only - Oct 11 3:00 0 -
# Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Casablanca -0:30:20 - LMT 1913 Oct 26
Le 30/09/2013 13:53, Milamber a ecrit :
Hello,
Please note too that the Moroccan government has change too the date to the beginning of DST at the last sunday of March (April before).
I've posted this mail because I think that the proposed patch seems not include this change and the management of Ramadan time (return to GMT+0 when the month of Ramadan is inside the DST time). Milamber
Source: http://www.mmsp.gov.ma/fr/actualites.aspx?id=395 == French == [...] Le décret en question établit d'ailleurs que dorénavant, on avancera d'une heure nos montres par rapport à l'heure de Greenwich (GMT) à la fin de chaque mois de mars et on retournera à " l'heure d'hiver " à la fin de chaque mois d'octobre.
== English translation via google == [...] The Decree also establishes that now, an hour we advance our watches over Greenwich Mean Time (GMT) at the end of each March and "winter time" we will return to at the end of every October.
Milamber
Le 30/09/2013 05:56, Paul Eggert a ecrit :
Come to think of it, my previously-proposed patch can't be right for 2036 and 2037. as the predicted dates for Ramadan in those years overlap the new fall-back dates. Here's a revised patch that takes this into account; this matters only for time stamps after 2035.
As a result of this change, Africa/Casablanca becomes the only Zone for which zic cannot generate a POSIX environment variable (for time stamps past 2038).
I've pushed this revised edition to the experimental version on github.
diff --git a/NEWS b/NEWS index 14f75fa..c89e339 100644 --- a/NEWS +++ b/NEWS @@ -3,6 +3,11 @@ News for the tz database
Unreleased, experimental changes
+ Changes affecting current and near-future time stamps + + Morocco changed their rules, and now falls back the first Sunday + in October, not September. (Thanks to Steffen Thorsen.) + Changes affecting 'zic'
'zic' now runs on platforms that lack both hard links and symlinks. diff --git a/africa b/africa index 9a5d93b..16fe153 100644 --- a/africa +++ b/africa @@ -858,13 +858,23 @@ Zone Indian/Mayotte 3:00:56 - LMT 1911 Jul # Mamoutzou # transitions would be 2013-07-07 and 2013-08-10; see: #http://www.maroc.ma/en/news/morocco-suspends-daylight-saving-time-july-7-aug...
-# From Paul Eggert (2013-07-03): +# From Steffen Thorsen (2013-09-28): +# Morocco extends DST by one month, on very short notice, just 1 day +# before it was going to end. There is a new decree (2.13.781) for +# this, where DST from now on goes from last Sunday of March at 02:00 +# to last Sunday of October at 03:00, similar to EU rules. Official +# source (French): +#http://www.maroc.gov.ma/fr/actualites/lhoraire-dete-gmt1-maintenu-jusquau-27... +# 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-29): # To estimate what the Moroccan government will do in future years, -# transition dates for 2014 through 2021 were determined by running +# 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 1444) +# (while (< islamic-year 1460) # (let ((a # (calendar-gregorian-from-absolute # (calendar-islamic-to-absolute (list 9 1 islamic-year)))) @@ -880,12 +890,12 @@ Zone Indian/Mayotte 3:00:56 - LMT 1911 Jul # Mamoutzou # (setq islamic-year (+ 1 islamic-year)))) # # with the results hand-edited for 2020-2022, when the normal spring-forward -# date falls during the estimated Ramadan. -# -# From 2023 through 2038 Ramadan is not predicted to overlap with -# daylight saving time. Starting in 2039 there will be overlap again, +# date falls during the estimated Ramadan; with results removed for 2023-2035, +# where the estimated Ramadan falls entirely outside daylight-saving time, +# and the results hand-edited again 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 2038. +# about dates after 2037.
# RULE NAME FROM TO TYPE IN ON AT SAVE LETTER/S
@@ -913,11 +923,12 @@ Rule Morocco 2010 only - Aug 8 0:00 0 - Rule Morocco 2011 only - Apr 3 0:00 1:00 S Rule Morocco 2011 only - Jul 31 0 0 - Rule Morocco 2012 2019 - Apr lastSun 2:00 1:00 S -Rule Morocco 2012 max - Sep lastSun 3:00 0 - +Rule Morocco 2012 only - Sep 30 3:00 0 - Rule Morocco 2012 only - Jul 20 3:00 0 - Rule Morocco 2012 only - Aug 20 2:00 1:00 S Rule Morocco 2013 only - Jul 7 3:00 0 - Rule Morocco 2013 only - Aug 10 2:00 1:00 S +Rule Morocco 2013 2035 - Oct lastSun 3:00 0 - Rule Morocco 2014 only - Jun 29 3:00 0 - Rule Morocco 2014 only - Jul 29 2:00 1:00 S Rule Morocco 2015 only - Jun 18 3:00 0 - @@ -934,6 +945,8 @@ Rule Morocco 2020 only - May 24 2:00 1:00 S Rule Morocco 2021 only - May 13 2:00 1:00 S Rule Morocco 2022 only - May 3 2:00 1:00 S Rule Morocco 2023 max - Apr lastSun 2:00 1:00 S +Rule Morocco 2036 only - Oct 21 3:00 0 - +Rule Morocco 2037 only - Oct 11 3:00 0 -
# Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Casablanca -0:30:20 - LMT 1913 Oct 26
Milamber wrote:
Please note too that the Moroccan government has change too the date to the beginning of DST at the last sunday of March (April before).
Thanks, the following additional patch should fix that bug. I've pushed this.
From 0a6a92937fd76cb05c401ac74909d6f7cea14a2a Mon Sep 17 00:00:00 2001 From: Paul Eggert <eggert@cs.ucla.edu> Date: Mon, 30 Sep 2013 09:01:01 -0700 Subject: [PATCH] Morocco changed start-of-DST from March to April.
* africa (Morocco): The spring-forward date was moved too, to the last Sunday in March. * NEWS: Document this. --- NEWS | 5 +++-- africa | 22 +++++++++++++++------- 2 files changed, 18 insertions(+), 9 deletions(-) diff --git a/NEWS b/NEWS index c89e339..316893b 100644 --- a/NEWS +++ b/NEWS @@ -5,8 +5,9 @@ Unreleased, experimental changes Changes affecting current and near-future time stamps - Morocco changed their rules, and now falls back the first Sunday - in October, not September. (Thanks to Steffen Thorsen.) + Morocco now observes DST from the last Sunday in March to the last + Sunday in October, not April to September respectively. (Thanks + to Steffen Thorsen.) Changes affecting 'zic' diff --git a/africa b/africa index 16fe153..20b00eb 100644 --- a/africa +++ b/africa @@ -868,7 +868,7 @@ 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-29): +# From Paul Eggert (2013-09-30): # 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: @@ -889,10 +889,11 @@ Zone Indian/Mayotte 3:00:56 - LMT 1911 Jul # Mamoutzou # (car (cdr (cdr b))) (calendar-month-name (car b) t) (car (cdr b))))) # (setq islamic-year (+ 1 islamic-year)))) # -# with the results hand-edited for 2020-2022, when the normal spring-forward -# date falls during the estimated Ramadan; with results removed for 2023-2035, -# where the estimated Ramadan falls entirely outside daylight-saving time, -# and the results hand-edited again for 2036-2037, where the normal fall-back +# with spring-forward transitions removed for 2023-2025, when the +# normal spring-forward date falls during the estimated Ramadan; with +# 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. @@ -922,13 +923,14 @@ Rule Morocco 2010 only - May 2 0:00 1:00 S Rule Morocco 2010 only - Aug 8 0:00 0 - Rule Morocco 2011 only - Apr 3 0:00 1:00 S Rule Morocco 2011 only - Jul 31 0 0 - -Rule Morocco 2012 2019 - Apr lastSun 2:00 1:00 S +Rule Morocco 2012 2013 - Apr lastSun 2:00 1:00 S Rule Morocco 2012 only - Sep 30 3:00 0 - Rule Morocco 2012 only - Jul 20 3:00 0 - Rule Morocco 2012 only - Aug 20 2:00 1:00 S Rule Morocco 2013 only - Jul 7 3:00 0 - Rule Morocco 2013 only - Aug 10 2:00 1:00 S Rule Morocco 2013 2035 - Oct lastSun 3:00 0 - +Rule Morocco 2014 2022 - Mar lastSun 2:00 1:00 S Rule Morocco 2014 only - Jun 29 3:00 0 - Rule Morocco 2014 only - Jul 29 2:00 1:00 S Rule Morocco 2015 only - Jun 18 3:00 0 - @@ -941,10 +943,16 @@ Rule Morocco 2018 only - May 16 3:00 0 - Rule Morocco 2018 only - Jun 15 2:00 1:00 S Rule Morocco 2019 only - May 6 3:00 0 - Rule Morocco 2019 only - Jun 5 2:00 1:00 S +Rule Morocco 2020 only - Apr 24 3:00 0 - Rule Morocco 2020 only - May 24 2:00 1:00 S +Rule Morocco 2021 only - Apr 13 3:00 0 - Rule Morocco 2021 only - May 13 2:00 1:00 S +Rule Morocco 2022 only - Apr 3 3:00 0 - Rule Morocco 2022 only - May 3 2:00 1:00 S -Rule Morocco 2023 max - Apr lastSun 2:00 1:00 S +Rule Morocco 2023 only - Apr 22 2:00 1:00 S +Rule Morocco 2024 only - Apr 10 2:00 1:00 S +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 - -- 1.8.1.2
When I tried to import tzdata2013g into our project, I realized 2013g Morocco rule change revealed our tooling problem. Our tool tries to extract a set of rules to be applied beyond year 2038, and expecting either no "max" rule or a pair of "max" rules. However, Africa/Casablanca with 2013g update introduced a case not fall into above - only a single "max" rule. Of course, tzcode works fine and it's our tooling issue. My problem is how we should interpret the rule. Below is a part of Morocco rules: Rule Morocco 2013 only - Jul 7 3:00 0 - Rule Morocco 2013 only - Aug 10 2:00 1:00 S Rule Morocco 2013 2035 - Oct lastSun 3:00 0 - Rule Morocco 2014 2022 - Mar lastSun 2:00 1:00 S Rule Morocco 2014 only - Jun 29 3:00 0 - Rule Morocco 2014 only - Jul 29 2:00 1:00 S Rule Morocco 2015 only - Jun 18 3:00 0 - Rule Morocco 2015 only - Jul 18 2:00 1:00 S Rule Morocco 2016 only - Jun 7 3:00 0 - Rule Morocco 2016 only - Jul 7 2:00 1:00 S Rule Morocco 2017 only - May 27 3:00 0 - Rule Morocco 2017 only - Jun 26 2:00 1:00 S Rule Morocco 2018 only - May 16 3:00 0 - Rule Morocco 2018 only - Jun 15 2:00 1:00 S Rule Morocco 2019 only - May 6 3:00 0 - Rule Morocco 2019 only - Jun 5 2:00 1:00 S Rule Morocco 2020 only - Apr 24 3:00 0 - Rule Morocco 2020 only - May 24 2:00 1:00 S Rule Morocco 2021 only - Apr 13 3:00 0 - Rule Morocco 2021 only - May 13 2:00 1:00 S Rule Morocco 2022 only - Apr 3 3:00 0 - Rule Morocco 2022 only - May 3 2:00 1:00 S Rule Morocco 2023 only - Apr 22 2:00 1:00 S Rule Morocco 2024 only - Apr 10 2:00 1:00 S 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 - If I read above, the rule applicable 2038 and beyond is only
Rule Morocco 2026 max - Mar lastSun 2:00 1:00 S
Therefore, if I read this as is, Africa/Casablanca will be permanent daylight saving time after 2038-03-28. I know the tz database is trying to cover dates up to 2037 (max signed integer seconds). Also, rules used in far future are not really useful. But users like us really need to make a certain assumption for far future dates. 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. My comments below is based on the assumption that the tz database just set 2038 as the threshold for rule coverage, but not trying to introduce the hard barrier. One thing I'm not comfortable is that the rules above will result permanent daylight saving time. If the max line rule were written like below - Rule Morocco 2026 2037 - Mar lastSun 2:00 1:00 S it makes better sense to me. The rule above indicates the last transition is on 2037-10-11, then it will stay in standard time beyond 2038. This is perfectly equivalent to what 2013g defined until 2038. Only the difference is 2038-03-28 (out of signed 32bit integer seconds) and beyond. I would like to ask the tz database coordinators to select rule line more friendly for users using the database for 2038 and beyond. Thanks, Yoshito
I unfortunately have run into the same problem with my own product. I'm very interested in knowing as well how this should be interpretted. On 2013-10-02 19:29, yoshito_umaoka@us.ibm.com wrote:
When I tried to import tzdata2013g into our project, I realized 2013g Morocco rule change revealed our tooling problem.
Our tool tries to extract a set of rules to be applied beyond year 2038, and expecting either no "max" rule or a pair of "max" rules. However, Africa/Casablanca with 2013g update introduced a case not fall into above - only a single "max" rule.
Of course, tzcode works fine and it's our tooling issue. My problem is how we should interpret the rule.
Below is a part of Morocco rules:
Rule Morocco 2013 only - Jul 7 3:00 0 - Rule Morocco 2013 only - Aug 10 2:00 1:00 S Rule Morocco 2013 2035 - Oct lastSun 3:00 0 - Rule Morocco 2014 2022 - Mar lastSun 2:00 1:00 S Rule Morocco 2014 only - Jun 29 3:00 0 - Rule Morocco 2014 only - Jul 29 2:00 1:00 S Rule Morocco 2015 only - Jun 18 3:00 0 - Rule Morocco 2015 only - Jul 18 2:00 1:00 S Rule Morocco 2016 only - Jun 7 3:00 0 - Rule Morocco 2016 only - Jul 7 2:00 1:00 S Rule Morocco 2017 only - May 27 3:00 0 - Rule Morocco 2017 only - Jun 26 2:00 1:00 S Rule Morocco 2018 only - May 16 3:00 0 - Rule Morocco 2018 only - Jun 15 2:00 1:00 S Rule Morocco 2019 only - May 6 3:00 0 - Rule Morocco 2019 only - Jun 5 2:00 1:00 S Rule Morocco 2020 only - Apr 24 3:00 0 - Rule Morocco 2020 only - May 24 2:00 1:00 S Rule Morocco 2021 only - Apr 13 3:00 0 - Rule Morocco 2021 only - May 13 2:00 1:00 S Rule Morocco 2022 only - Apr 3 3:00 0 - Rule Morocco 2022 only - May 3 2:00 1:00 S Rule Morocco 2023 only - Apr 22 2:00 1:00 S Rule Morocco 2024 only - Apr 10 2:00 1:00 S 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 -
If I read above, the rule applicable 2038 and beyond is only
Rule Morocco 2026 max - Mar lastSun 2:00 1:00 S
Therefore, if I read this as is, Africa/Casablanca will be permanent daylight saving time after 2038-03-28.
I know the tz database is trying to cover dates up to 2037 (max signed integer seconds). Also, rules used in far future are not really useful. But users like us really need to make a certain assumption for far future dates.
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. My comments below is based on the assumption that the tz database just set 2038 as the threshold for rule coverage, but not trying to introduce the hard barrier.
One thing I'm not comfortable is that the rules above will result permanent daylight saving time. If the max line rule were written like below -
Rule Morocco 2026 2037 - Mar lastSun 2:00 1:00 S
it makes better sense to me. The rule above indicates the last transition is on 2037-10-11, then it will stay in standard time beyond 2038. This is perfectly equivalent to what 2013g defined until 2038. Only the difference is 2038-03-28 (out of signed 32bit integer seconds) and beyond.
I would like to ask the tz database coordinators to select rule line more friendly for users using the database for 2038 and beyond.
Thanks, Yoshito
--
It is likely that this will affect my compilers too as we look for a far future repeating rule. Stephen On 3 October 2013 01:31, David Patte ₯ <dpatte@relativedata.com> wrote:
I unfortunately have run into the same problem with my own product. I'm very interested in knowing as well how this should be interpretted.
On 2013-10-02 19:29, yoshito_umaoka@us.ibm.com wrote:
When I tried to import tzdata2013g into our project, I realized 2013g Morocco rule change revealed our tooling problem.
Our tool tries to extract a set of rules to be applied beyond year 2038, and expecting either no "max" rule or a pair of "max" rules. However, Africa/Casablanca with 2013g update introduced a case not fall into above - only a single "max" rule.
Of course, tzcode works fine and it's our tooling issue. My problem is how we should interpret the rule.
Below is a part of Morocco rules:
Rule Morocco 2013 only - Jul 7 3:00 0 - Rule Morocco 2013 only - Aug 10 2:00 1:00 S Rule Morocco 2013 2035 - Oct lastSun 3:00 0 - Rule Morocco 2014 2022 - Mar lastSun 2:00 1:00 S Rule Morocco 2014 only - Jun 29 3:00 0 - Rule Morocco 2014 only - Jul 29 2:00 1:00 S Rule Morocco 2015 only - Jun 18 3:00 0 - Rule Morocco 2015 only - Jul 18 2:00 1:00 S Rule Morocco 2016 only - Jun 7 3:00 0 - Rule Morocco 2016 only - Jul 7 2:00 1:00 S Rule Morocco 2017 only - May 27 3:00 0 - Rule Morocco 2017 only - Jun 26 2:00 1:00 S Rule Morocco 2018 only - May 16 3:00 0 - Rule Morocco 2018 only - Jun 15 2:00 1:00 S Rule Morocco 2019 only - May 6 3:00 0 - Rule Morocco 2019 only - Jun 5 2:00 1:00 S Rule Morocco 2020 only - Apr 24 3:00 0 - Rule Morocco 2020 only - May 24 2:00 1:00 S Rule Morocco 2021 only - Apr 13 3:00 0 - Rule Morocco 2021 only - May 13 2:00 1:00 S Rule Morocco 2022 only - Apr 3 3:00 0 - Rule Morocco 2022 only - May 3 2:00 1:00 S Rule Morocco 2023 only - Apr 22 2:00 1:00 S Rule Morocco 2024 only - Apr 10 2:00 1:00 S 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 -
If I read above, the rule applicable 2038 and beyond is only
Rule Morocco 2026 max - Mar lastSun 2:00 1:00 S
Therefore, if I read this as is, Africa/Casablanca will be permanent daylight saving time after 2038-03-28.
I know the tz database is trying to cover dates up to 2037 (max signed integer seconds). Also, rules used in far future are not really useful. But users like us really need to make a certain assumption for far future dates.
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. My comments below is based on the assumption that the tz database just set 2038 as the threshold for rule coverage, but not trying to introduce the hard barrier.
One thing I'm not comfortable is that the rules above will result permanent daylight saving time. If the max line rule were written like below -
Rule Morocco 2026 2037 - Mar lastSun 2:00 1:00 S
it makes better sense to me. The rule above indicates the last transition is on 2037-10-11, then it will stay in standard time beyond 2038. This is perfectly equivalent to what 2013g defined until 2038. Only the difference is 2038-03-28 (out of signed 32bit integer seconds) and beyond.
I would like to ask the tz database coordinators to select rule line more friendly for users using the database for 2038 and beyond.
Thanks, Yoshito
--
yoshito_umaoka@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@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
Paul Eggert 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.
Of cause while the number of people affected by 'pre-history' dates with time is not so great, nowadays the 2038 rollover has to be taken seriously, and anybody still stuck with software affected by it needs to be considering the problem. With mortgages and pension dates for many people well beyond this any mainstream system that has not already switched to 64 bit timestamps are already unusable? And while we know that DST data could probably change in the interveaning 25 years, legal documents do tend to work to an exact time in the future. But they are probably not using time_t anyway for storage ... -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Paul, Should custom compilers be potentially supporting a single MAX situation? Could that situation ever be valid?
On 10/03/13 04:45, David Patte ₯ wrote:
Paul,
Should custom compilers be potentially supporting a single MAX situation? Could that situation ever be valid?
Yes and no. It does conform to the zic documentation, and zic works if you specify rules like that, but given what we've discovered with the 2013g rules for Morocco it appears that it's trouble for other applications and it most likely indicates a mistake of some sort in the data, which suggests that tzdata files shouldn't use this feature.
On Thu, Oct 3, 2013 at 3:36 AM, Lester Caine <lester@lsces.co.uk> wrote:
Of cause while the number of people affected by 'pre-history' dates with time is not so great, nowadays the 2038 rollover has to be taken seriously, and anybody still stuck with software affected by it needs to be
I'd just like to point out that there are already actively traded government bonds issued by the Kingdom of Morocco that mature in 2042 (12/11/2042 to be exact). The financial sector actively works with dates > 2037 all the time because bonds have very long time horizons. I've already run into bugs interfacing tzdata to JS interpreters where passing a date+midnight > 2037 will result in the (date - 1 day) due to the tzdata code believing there is no DST, but the script interpreter believes there is DST because the interpreter "maps" years > 2037 to equivalent prior years where there is data (which is broken, anyway -- fixed in ES6 spec, but just pointing out real-world encounters here). -Andrew
Lester Caine <lester@lsces.co.uk> writes:
Of cause while the number of people affected by 'pre-history' dates with time is not so great, nowadays the 2038 rollover has to be taken seriously, and anybody still stuck with software affected by it needs to be considering the problem. With mortgages and pension dates for many people well beyond this any mainstream system that has not already switched to 64 bit timestamps are already unusable?
The problem with some specific time zones, like Morocco, is that the time of DST is based on calculations that the tz software is not capable of representing as rules or doing internally. See the large comment in front of that zone. Instead, external software is used to generate the year-by-year rules going forward up to some (fairly arbitrary) cut-off point. (Even those are an approximation in this case and will probably require some last-minute fiddling in some years.) Obviously, we don't want to do that until the end of time (particularly since time has no end), but 2038 is getting closer, so maybe that isn't the best cut-off point any more. It might be interesting to do something like generate the rules 50 years into the future and automate some way of adding another year of rules each year. That said, Paul's proposed approach (if I understood it correctly) is to add an approximate static rule using the calculations the tz software can represent as rules for dates past 2038, and I suspect that, for right now, that will be good enough for most practical purposes. (It will become less useful the closer we get to 2038, of course.) -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
On Thu, Oct 3, 2013, at 12:24, Russ Allbery wrote:
The problem with some specific time zones, like Morocco, is that the time of DST is based on calculations that the tz software is not capable of representing as rules or doing internally. See the large comment in front of that zone. Instead, external software is used to generate the year-by-year rules going forward up to some (fairly arbitrary) cut-off point. (Even those are an approximation in this case and will probably require some last-minute fiddling in some years.)
These scripts should be included with the repository.
Obviously, we don't want to do that until the end of time (particularly since time has no end), but 2038 is getting closer, so maybe that isn't the best cut-off point any more. It might be interesting to do something like generate the rules 50 years into the future and automate some way of adding another year of rules each year.
Or do it until, say, 2100, and then extend it to 2200 in 2050, so there's always between 50 and 150 years of future data.
On 10/03/2013 07:07 PM, random832@fastmail.us wrote:
Or do it until, say, 2100, and then extend it to 2200 in 2050, so there's always between 50 and 150 years of future data. expanding to 2050 or 2100 is indeed not to far fetched to use as a general rule, but then you still have the "one max" (to) rule (them all).
IMHO it's actually not really relevant what the result is, as long as there is both an end and begin for the same year defined, even if it's outside the "end year" that is supposed. so OR adding someting like
+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 -
(or the equivalent of whatever "end year" is chosen) makes sense imho, even if the resulting data is "weird" or unlikely. Or change
Rule Morocco 2026 max - Mar lastSun 2:00 1:00 S to Rule Morocco 2026 2037 - Mar lastSun 2:00 1:00 S
It's quite possible those transitions will change 20 times the next 50 year anyway:)
On 10/03/2013 06:24 PM, Russ Allbery wrote:
It might be interesting to do something like generate the rules 50 years into the future and automate some way of adding another year of rules each year. I doubt it's worth bothering .
AFAIK this is only for the marroco rules who , as showed in other replies, become rather "silly" anyway. There seams to be no added value in trying to generate extra rules for DST up to like 2050, it think it's best (even if it's arbitray) to say like "after this year, stop, it's getting a bit to silly" for rules like this. With 2038 clearly being very silly . So after thinking it a bit over removing the max of the spring change for marocco and use the end of "estimated" changes makes most sense to me. This also leaves people free to use for "max" whatever year (2050, 2100) they choose.
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.
Thank you Paul for taking an action for this one. I have some questions in your suggested update:
+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 -
With this change, GMT offset at Africa/Casablanca around year 2038 would be - Rule Morocco 2037 only - Oct 11 3:00 0 - 2038-01-01 - GMT+0 Rule Morocco 2026 max - Mar lastSun 2:00 1:00 S 2038-03-28 - GMT+0 -> GMT+1 Rule Morocco 2038 only - Sep 30 3:00 0 - 2038-09-30 - GMT+1 -> GMT+0 Rule Morocco 2038 only - Oct 30 2:00 1:00 S 2038-10-30 - GMT+0 -> GMT+1 Rule Morocco 2038 max - Oct lastSun 3:00 0 - 2038-10-31 - GMT+1 -> GMT+0 For me, above GMT offset transition looks really weird. I suspect what you really wanted to suggest would be: +Rule Morocco 2038 only - Sep 30 3:00 0 - +Rule Morocco 2039 max - Oct lastSun 3:00 0 - Thanks, Yoshito
On 10/03/13 09:51, yoshito_umaoka@us.ibm.com wrote:
For me, above GMT offset transition looks really weird.
It is weird, but the question is how much judgment we should use when guessing the future. In the latest experimental version, the transitions predicted for 2038 are: Sun Mar 28 01:59:59 2038 UT = Sun Mar 28 01:59:59 2038 WET isdst=0 Sun Mar 28 02:00:00 2038 UT = Sun Mar 28 03:00:00 2038 WEST isdst=1 Thu Sep 30 01:59:59 2038 UT = Thu Sep 30 02:59:59 2038 WEST isdst=1 Thu Sep 30 02:00:00 2038 UT = Thu Sep 30 02:00:00 2038 WET isdst=0 Sat Oct 30 01:59:59 2038 UT = Sat Oct 30 01:59:59 2038 WET isdst=0 Sat Oct 30 02:00:00 2038 UT = Sat Oct 30 03:00:00 2038 WEST isdst=1 Sun Oct 31 01:59:59 2038 UT = Sun Oct 31 02:59:59 2038 WEST isdst=1 Sun Oct 31 02:00:00 2038 UT = Sun Oct 31 02:00:00 2038 WET isdst=0 This predicts that Morocco will observe DST during just a one-day period, from October 30 to October 31, because Ramadan ends on the 30th (thus restoring DST) and the DST-end period is October 31 (thus reverting to standard time). Which is pretty weird -- will Moroccans really change their clocks twice in two days? So it's tempting to omit the last two transitions. But let's look at 2022: Sun Mar 27 01:59:59 2022 UT = Sun Mar 27 01:59:59 2022 WET isdst=0 Sun Mar 27 02:00:00 2022 UT = Sun Mar 27 03:00:00 2022 WEST isdst=1 Sun Apr 3 01:59:59 2022 UT = Sun Apr 3 02:59:59 2022 WEST isdst=1 Sun Apr 3 02:00:00 2022 UT = Sun Apr 3 02:00:00 2022 WET isdst=0 Tue May 3 01:59:59 2022 UT = Tue May 3 01:59:59 2022 WET isdst=0 Tue May 3 02:00:00 2022 UT = Tue May 3 03:00:00 2022 WEST isdst=1 Sun Oct 30 01:59:59 2022 UT = Sun Oct 30 02:59:59 2022 WEST isdst=1 Sun Oct 30 02:00:00 2022 UT = Sun Oct 30 02:00:00 2022 WET isdst=0 This predicts that Moroccans will change their clocks twice in 8 days. Not as weird, but still pretty weird, and it's tempting to omit the first two transitions. But then the question is, where does one stop omitting transitions? The answer to this question depends on how much of a stickler Moroccans will be for following the rules, and that involves complex religious-commercial-political tradeoffs that I don't pretend to understand. In the current experimental version I didn't omit any of the predicted transitions, as that was one less thing for me to worry about, but if there's consensus to omit them if they would imply moving the clocks less than N days apart we can do that too.
On 2013-10-03 21:11, Paul Eggert wrote:
This predicts that Moroccans will change their clocks twice in 8 days. Not as weird, but still pretty weird, and it's tempting to omit the first two transitions. But then the question is, where does one stop omitting transitions?
The answer to this question depends on how much of a stickler Moroccans will be for following the rules, and that involves complex religious-commercial-political tradeoffs that I don't pretend to understand. In the current experimental version I didn't omit any of the predicted transitions, as that was one less thing for me to worry about, but if there's consensus to omit them if they would imply moving the clocks less than N days apart we can do that too.
IMHO it's not worth worrying about. It's not as if any of the listed transition dates (particularly the "suspension of DST during Ramadan" dates) are fixed in stone anyway. The Moroccan government may decide to suspend DST a day earlier than predicted one year for example. -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
On 4 October 2013 10:18, Ian Abbott <abbotti@mev.co.uk> wrote:
On 2013-10-03 21:11, Paul Eggert wrote:
This predicts that Moroccans will change their clocks twice in 8 days. Not as weird, but still pretty weird, and it's tempting to omit the first two transitions. But then the question is, where does one stop omitting transitions?
The answer to this question depends on how much of a stickler Moroccans will be for following the rules, and that involves complex religious-commercial-political tradeoffs that I don't pretend to understand. In the current experimental version I didn't omit any of the predicted transitions, as that was one less thing for me to worry about, but if there's consensus to omit them if they would imply moving the clocks less than N days apart we can do that too.
IMHO it's not worth worrying about. It's not as if any of the listed transition dates (particularly the "suspension of DST during Ramadan" dates) are fixed in stone anyway. The Moroccan government may decide to suspend DST a day earlier than predicted one year for example.
Exactly. The future rules are a best efforts pattern for the future. Their accuracy will obviously fall as they go further into the future. Ultimately, the most that can be expressed in that the concept of DST is likely to continue, not exact dates. My approach would be that if a country/zone/ID has DST now and looks likely to continue using it then the rules must end in a matched pair of "max" transitions. I think such an approach would handle this case. Personally, I would have only pre-generated the guesses for a shorter timescale of say the next 10 years before going onto a generalised max rule. But pre-generating to 2037 isn't "wrong", just a choice. Finally, I note that applications are used to handling tz rules that change in the future. My experience is that they are less well setup to handle rules changes affecting the past, hence recent discussion. Stephen
participants (12)
-
Andrew Paprocki -
David Patte ₯ -
gunther Vermeir -
Ian Abbott -
Lester Caine -
Milamber -
Paul Eggert -
random832＠fastmail.us -
Russ Allbery -
Steffen Thorsen -
Stephen Colebourne -
yoshito_umaoka＠us.ibm.com