Re: [PATCH v2] localedata: CLDRv29: update LC_ADDRESS.country_num values

[Carlos O'Donell <carlos at redhat dot com>]

On 04/13/2016 01:38 PM, Mike Frysinger wrote:
> On 13 Apr 2016 17:18, Andreas Schwab wrote:
>> Mike Frysinger <vapier@gentoo.org> writes:
>>> On 13 Apr 2016 09:23, Andreas Schwab wrote:
>>>> Either country_num is a plain number, then it should be written as a
>>>> plain number since the leading zero is ignored, or the leading zero is
>>>> significant, then it must be encoded as a string to preserve it.
>>>
>>> it isn't a string, it's a decimal number.  the code enforces it.
>>> the leading zero is insignificant here once it's been encoded which
>>> leaves it as a style choice in the source locales.  since the files
>>> are meant to match the standards, using the style of the standards
>>> makes sense.
>>
>> Just because the standard is confusing doesn't mean we have to follow
>> it.
> 
> i don't find the standard confusing at all.  what i do find confusing is
> looking at the standard and all the downstream data stores (including,
> but not limited to, CLDR) use zero-padded 3 digits.  except glibc.  so
> then i have to spend time figuring out which is correct only to realize
> later that they're both correct in practice -- glibc internally stores
> the value as an integer, so leading zeros don't matter.  by keeping the
> locale files matching the standards, things are clear for people.

Agreed. The locale files should match the standard, as I noted up-stream
the standard is actually "a three-digit numeric code" and the leading zeros
are important in that definition that it be three-digits. If you were to
write a parser for the numeric codes you could write one that always assumes
there are three digits and you would be right.

-- 
Cheers,
Carlos.