[tz] 2013g - Morocco

David Patte ₯ dpatte at relativedata.com
Thu Oct 3 00:31:19 UTC 2013


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 at 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


-- 
  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20131002/f98d7698/attachment.htm>


More information about the tz mailing list