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_... 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_1... "{_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