This is the mail archive of the
mailing list for the glibc project.
Re: [RFC][PATCH] Multiple locales: Use the correct date and time formats (bug 10496, 23724).
- From: TAMUKI Shoichi <tamuki at linet dot gr dot jp>
- To: Rafal Luzynski <digitalfreak at lingonborough dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Thu, 08 Nov 2018 21:05:16 +0900
- Subject: Re: [RFC][PATCH] Multiple locales: Use the correct date and time formats (bug 10496, 23724).
- References: <email@example.com>
From: Rafal Luzynski <firstname.lastname@example.org>
Subject: Re: [RFC][PATCH] Multiple locales: Use the correct date and time formats (bug 10496, 23724).
Date: Mon, 5 Nov 2018 22:59:05 +0100 (CET)
> > if d_t_fmt which is fixed
> > width suddenly becomes variable width, I just thought that there might
> > be people in trouble.
> I'm trying to understand the use case where people might be in trouble
> if the date width varies. It it maybe that someone may be trying to extract
> pieces of the date (e.g., the current month or the current week day) from the
> output of date finding a substring at specified constant index? If yes then
> there are more reasons why this may not work, especially in non-English locales,
> and better ways to achieve the correct results.
For example, user-oriented software implemented to output logs using
%c, the preferred calendar time representation for the current locale
for the sake of clarity, will be inconvenient if the date and time
> > I have roughly checked in the current locale data to see which locale
> > uses a variable width at d_t_fmt. The result is:
> > ca_ES: "%A, %-d %B de %Y, %T %Z"
> > cs_CZ: "%a<U00A0>%-d.<U00A0>%B<U00A0>%Y,<U00A0>%H:%M:%S<U00A0>%Z"
> > hu_HU: "%Y. %b. %-e., %A, %H:%M:%S %Z"
> > it_CH: "%a %-d %b %Y, %T"
> > it_IT: "%a %-d %b %Y, %T"
> > nr_ZA: "%a %-e %b %Y %T %Z"
> > pl_PL: "%a, %-d %b %Y, %T"
> > ss_ZA: "%a %-e %b %Y %T %Z"
> > st_ZA: "%a %-e %b %Y %T %Z"
> > szl_PL: "%a, %-d %b %Y, %T"
> > tn_ZA: "%a %-e %b %Y %T %Z"
> > ts_ZA: "%a %-e %b %Y %T %Z"
> > xh_ZA: "%a %-e %b %Y %T %Z"
> Thank you for this survey! Yes, this is an evidence that variable width
> date formats may be acceptable.
These are only 13 locales out of the total 353 locales. Please note
that there are fixed-width date and time formats for almost all other
locales (96.3%) except the above.
> > For example, "LANG=C date" shows a space as padding to keep it a
> > constant width.
> This is a different case. When you execute "date" with no arguments
> it uses the date format which consists of numbers and words: day number,
> abbreviated month name, abbreviated weekday name, etc. It is correct
> to separate them with spaces, and not so bad to add more spaces, when
> needed. In my case I was referring to a string which consists exclusively
> of digits and punctuation characters (like 5.11.2018 or 11/5/18) which
> should not contain spaces. That's why zero-padding exists. (e.g.,
> 05.11.18 or 11/05/18). " 5.11.2018" may not be so bad but "11/ 5/18"
> is rather weird.
I agree. If you do not have any problems using zero-padding (e.g.,
05.11.18 or 11/05/18), I think it is a good choice.
By the way,
"9:00 a.m. - 5:00 p.m."
in English is translated as
"9:00 e paradites - 5:00 e pasdites"
So, should we include such a representation?