[tz] tz abbr too long in 2017a Africa/Monrovia [was: zic throws warning for 2007a]

Brian Inglis Brian.Inglis at Shaw.ca
Wed Mar 1 22:16:15 UTC 2017


On 2017-03-01 14:48, Tim Parenti wrote:
> On 1 March 2017 at 16:42, Brian Inglis wrote:
> Looks like it stores the over long abbreviation.
> So should probably patch:
>     --- tz/releases/tzdata2017a/africa      2017-02-23 00:37:19.000000000 -0700
>     +++ tz/releases/tzdata2017b/africa      2017-03-01 14:36:43.479882200 -0700
>     @@ -431,7 +431,7 @@ Link Africa/Nairobi Indian/Mayotte
>      # Zone NAME            GMTOFF  RULES   FORMAT  [UNTIL]
>      Zone   Africa/Monrovia -0:43:08 -      LMT     1882
>                             -0:43:08 -      MMT     1919 Mar # Monrovia Mean Time
>     -                       -0:44:30 -      -004430 1972 May
>     +                       -0:44:30 -      -0044   1972 May
>                              0:00   -       GMT
> The above patch would be incorrect, though. It would be more correct
> to increase the allowed max abbreviation length. (Even better,
> numerical "abbreviations" like this should just be exempted from the
> caps, since they can technically be of almost any length, even though
> this is the longest they'll be in practice.)

POSIX limit in limits.h:

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03
under TZ definition for std and dst (abbrs) 
"The interpretation of these fields is unspecified if either field is 
less than three bytes (except for the case when dst is missing), more 
than {TZNAME_MAX} bytes, or if they contain characters other than those 
specified."

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html#tag_13_23_03_05
"{_POSIX_TZNAME_MAX}
    Maximum number of bytes supported for the name of a timezone (not of 
    the TZ variable).
    Value: 6"

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada



More information about the tz mailing list