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