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