[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.html>
More information about the tz
mailing list