[tz] 2013g - Morocco

yoshito_umaoka at us.ibm.com yoshito_umaoka at us.ibm.com
Wed Oct 2 23:29:53 UTC 2013


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20131002/1d22eeaa/attachment-0001.html>


More information about the tz mailing list