[tz] tz abbr too long in 2017a Africa/Monrovia [was: zic throws warning for 2007a]
Brian Inglis
Brian.Inglis at SystematicSw.ab.ca
Fri Mar 3 02:50:29 UTC 2017
On 2017-03-02 18:47, Jonathan Leffler wrote:
> On Wed, Mar 1, 2017 at 2:16 PM, Brian Inglis wrote:
>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"
> Note that the spiel above the entry for {_POSIX_TZNAME_MAX} says:
> The /<limits.h>/ header shall define the following symbolic constants
> with the values shown. These are the most restrictive values for
> certain features on an implementation conforming to this volume of
> POSIX.1-2008. Related symbolic constants are defined elsewhere in
> this volume of POSIX.1-2008 which reflect the actual implementation
> and which need not be as restrictive. For each of these limits, a
> conforming implementation shall provide a value at least this large
> or shall have no limit. A strictly conforming application must not
> require a larger value for correct operation.
> Is the code in tzcode intended to be a strictly conforming
> application?
From:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap02.html#tag_02_02_01
the application is not a Strictly Conforming POSIX Application as it
does not #define _POSIX_C_SOURCE 200809L, and is not a Conforming
POSIX Application as it does not include a "statement of conformance
that documents all options and limit dependencies, and all other ISO
or IEC standards used", although commentary indicates POSIX
compliance where notable.
AFAICT like many packages, it is intended to be POSIX compliant and
provide POSIX compliant implementations, to be portable to POSIX
compliant and some non-POSIX systems.
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
More information about the tz
mailing list