[tz] 2013g - Morocco
Stephen Colebourne
scolebourne at joda.org
Thu Oct 3 01:19:08 UTC 2013
It is likely that this will affect my compilers too as we look for a
far future repeating rule.
Stephen
On 3 October 2013 01:31, David Patte ₯ <dpatte at relativedata.com> wrote:
> 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
>
>
>
> --
>
More information about the tz
mailing list