Re: Talk about glibc locale format

[Keld Jørn Simonsen <keld at dkuug dot dk>]

On Fri, Jul 08, 2005 at 01:00:39AM +0200, Denis Barbier wrote:
> [dropping debian-i18n, this discussion is more relevant to libc-locales]
> 
> On Thu, Jul 07, 2005 at 12:32:21AM +0200, Keld JÃrn Simonsen wrote:
> [...]
> > On Wed, Jul 06, 2005 at 12:20:00AM +0200, Denis Barbier wrote:
> > > My example was not very good, one can indeed assume that cal writers
> > > are able to make such date computations.  But the problem is that
> > > ISO 14652 new definition is not compatible with "struct tm" as described
> > > in http://www.opengroup.org/onlinepubs/009695399/basedefs/time.h.html
> > > so any libc function (like gmtime, localtime, strftime,...) which work
> > > with "struct tm" is no more POSIX compatible. 
> > 
> > Why is it not compatible? It is easy to convert the specs in strings of
> > 14652 to that data format. Even I could do that! The only problem is
> > that there is a spec that says what the first weekday is, and then a
> > correspondance to the individual daynames. If the week was 7 days (which
> > is almost universal) and the week begins on a monday, then you just have
> > to rearrange the strings a little. I am not sure if the week begins
> > on a saturday in some countries, I think there may be a case for arabic
> > countries there. But it is easy from the specs to arrange normal 7 day
> > weeks in an internal format that is conformant to POSIX. And then from
> > there the APIs work.
> 
> All right, I now see your point, thank you for explaining.
> The new version at
>   http://people.debian.org/~barbier/talks/debconf5/glibc-locale.pdf
> should address all your remarks.

Good!

One small error at page 11: coode -> code

On page 13, I have suggested a value of say 1997 to indicate glibc
implementation.

You say that glibc is based on an early draft of 14652, which is true.
The differences between that draft (I think it was the FCD) and the final
specification is quite small, probably smaller than the say 7 years it
took to complete the specification would suggest. I think the few
differences are: removal of LC_PAPER, removal of ..(2).. and moving of
the transliteartion stuff to LC_TRANSLITERATE - that is all.

Page 24: actually it was the Finnish locale that made us introduce the
int_p_cs_precedes etc, because they wanted the currency et to be placed
differently if EUR was used or if â was used. eg  EUR 23,40 vs. 23,40 â
(well the discussion was taken when they still were using finmarks).
These new "int" variables were then also introduced in the POSIX and C
standards.

page 26: fonctions -> functions.

I understand that you may consider the date things for overdesigned. The
support for a week length different from 7 is probably never going to be
used. But I had also to prove to some that there were new features in
the spec, some people said that there were not enough new stuff to warrant a
new ISO publication. So that is why things like LC_ADDRESS and
LC_TELEPHONE came into the spec, and the week length also came in partly
because of this, partly because we then could handle the weeks under the
French revolution in the late 1700's. 

Anyway, I think what is asked for in parsing the locale for 14652 is
probably in the order of 20 lines more code than a more simplistic 
specification method. That is not much difference, but enough to annoy 
a lot of people.

> > > There are 2 distinct problems:
> > >   a. How to specify first day of week?
> > >   b. How to handle different calendars?
> > > (a) could have been easily solved by setting first_weekday to a value
> > > between 0 and 6 (i.e. with a semantics similar to %w, 0=Sunday ...
> > > 6=Saturday).
> > 
> > Well, the current semantics of 14652 is similar to that, the only thing
> > is Sunday=7.
> 
> I disagree again, Sunday=7 only if the first day specified in the "week"
> field corresponds to a Monday.  E.g. if "week" is 7;19971130;7, then
> 1=Sunday.

Hmm, what 14652 says is that the first day of the week is given by the
date 19971130. This was done to be able to cater for other week lengths 
than 7. 

anyway, yuu are right, in 14652 if the week begins on a sunday, then
sunday=1. I am not sure what that affects tho. It does not affect 14652
%u and %w.


> As you explain, libc can internally store another value (which is then
> identical to mine), but I still prefer my solution (which is much more
> simple) until you implement yours and receive support from users ;)
> 
> > This is easy to handle: if (day ==7) day= 0;
> > And then with sunday=7 there is a direct correspondance to ISO 8601.
> > Also one of the aims of 14652 was to get national ISO members to
> > do or be involved in making the locales. For them it is not natural that
> > Sunday is 0. It is more natural for them to follow ISO 8601 day
> > numbering, which is almost the same.
> 
> This is also true with my solution.

I don't know your solution. Is it described and implemented?

Best regards
keld