Re: Talk about glibc locale format

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

On Wed, Jul 06, 2005 at 12:20:00AM +0200, Denis Barbier wrote:
> On Tue, Jul 05, 2005 at 09:37:30PM +0200, Keld Jørn Simonsen wrote:
> [...]
> > Anyway,could the programmers of cal obtain the parameters of the week
> > keyword and then handle the day names accordingly?
> > Is this the problem, that they cannot obtain the "week" line in a
> > reliable way?
> > 
> > Then one could ahve 3 keywords instead
> > 
> > weeklength  7               #  indicating a normal week length of 7 days)
> > firstweekbegin 4            # a Thursday
> > firstdayofweek 19971201     # a Monday
> > 
> > The cal programmer then needs to do some programming.
> 
> 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.


> There are some side
> effects, e.g. strftime %w would become locale-dependent.

Not as far as I can tell. %w is defined as 0-6, 0=Sunday, in both POSIX
and 14652. No change.

> OTOH if libc functions are not modified, all applications calling
> these functions need to be modified.

Most libc functions need not be modified, but as part of parsing the
14652 locale, the data needs to be translated into POSIX/libc internal
values.

> 
> This is very different from other changes, say in LC_COLLATE, because
> new keywords in this section only modified the locale file format, not
> libc API.

As I show above, you can easily run with POSUX structs unchanged.
Except with weeks longer than 7, and more than 12 months,
- then you need to add some space.

> > It should be easy to determine what day the firstdayofweek is
> > in the range 1 thru weeklength (normally Monday thru Sunday).
> > 
> > A calender should display the week number with the calender
> > so that needs to be computed, the start of the first week.
> > 
> > Then the calender should be displayable. 
> > 
> > I don't think that you need more info than this, and all this is not
> > really complicated.
> 
> This should be easy for cal writers, but I hope that any programer
> wanting to display a date does not need to make such computations ;)

The handling should be hidden in libc, and then the programmers should just call
the libc locale dependent apis, and then everything works. This is the
normal model of i18n. Programmers need not know anything about strange
cultures.
> 
> > But maybe people get confused by requiring Monday=1, Sunday=7 ?
> > But this is standard ISO 8601, and what is the case in most of the
> > world.
> 
> No, people get confused because:
>   1. the definitions of day and abday are not compatible with POSIX.

I still maintain they are compatible, but they are enhanced.

>   2. there is no implementation of this standard

Yes, that is a problem. And maybe there would be a better way forward to
implement the fuctionality. Or maybe we should just give it some
thoughts and then implement it. It seems that the problems are not so
big.

> > Given the importance of time and calendars, and also week numbers, 
> > this is functionlity that should be implemented. Maybe there is better
> > way to specify it, 
> > 
> > So you suggest other keywords?
> > 
> > Like:
> > 
> > intabday "ma","ti","on","to","fr","lø","sø"  # Danish
> > 
> > Should I then also have:
> > 
> > abday "sø","ma","ti","on","to","fr","lø"
> > 
> > That would seem completely unnecessary as just a duplication of the 
> > "intabday" information. 
> 
> 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. 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.


> I have no idea about (b), people using these calendars
> surely have some ideas.  And if nobody knows how to work with different
> calendars, I would not try to standardize anything about that ;)

Yes, that is difficult. But we want to cover as much as the world as
possible, with each of their specific cultural requirements. Then we
need to work together with the experts of each culture, and try to make
it fit into a general i18n system. That is a job than can be done, even
if you and I are not experts of the specific culture.

Best regards
Keld