Bug#913348: Locale "i18n" has possibly a wrong value in LC_ADDRESS category
Locale "i18n" may have a bug in LC_ADDRESS category as it has the value:
that gives "%a%N%f%N%d%N%b%N%s %h %e %r%N%C-%z %T%N%c%N"
instead of "%n%N%a%N%f%N%d%N%b%N%s %h %e %r%N%l%N%C-%z %T%N%S%N%c%N"
which I found in ISO/IEC TR 14652:2002 at
(on page 55). Missing fields seems to be "%n%N", "%l%N" and "%S%N".
Probably this should be verified with the current version of the
standard full text which I did not find easily available. But it seems
logical that an address begins with "Person's name" ("%n%N") and
contains also the "%l%N" and "%S%N" fields.
Also the "locales" package from Debian unstable (version 2.27-8) has the
same and possibly wrong value "%a%N%f%N%d%N%b%N%s %h %e %r%N%C-%z
%T%N%c%N" in the LC_ADDRESS category in the
Anyway I am not sure if any software on my Debian systems actually uses
the LC_ADDRESS category, so I probably cannot test what problems this
causes (if any). I just noticed this problem by accident when fighting
an uphill battle with Mozilla Thunderbird about formating dates and
times using a clear ISO way instead of crazy ambiguous formats in
various locales (e.g. en_US or cs_CZ etc.). Well maybe when the Borg
assimilate us we will finally be able to agree on doing basic things in
one standard and most efficient way:D. Until then lets enjoy arguing
about miles vs kilometers, AM/PM vs 24H, date formats, timezones,
languages and other nonsense:).