This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] en_US: define date_fmt (bug 24046)
On 2019-01-05 01:19, Rafal Luzynski wrote:
> 3.01.2019 00:47 Aurelien Jarno <aurelien@aurel32.net> wrote:
> > [...]
> > My point was that country spanning multiple time zones usually (or
> > should?) already have the time zone indicated in d_t_fmt, so d_t_fmt and
> > date_fmt should be the same. At least that was my impression looking
> > only at a few locales.
> >
> > However after grepping the existing locales, it is not that clear
> > anymore. The presence of %z or %Z in d_t_fmt seems mostly random. And
> > often different in t_fmt...
>
> I'm not aware of any rule saying whether d_t_fmt should include a time
> zone or not. Additionally, date_fmt is a GNU extension. But I perceive
> the built in C locale as a model implementation. Other locales may be
> pretty sloppy. In C locale the only difference between d_t_fmt and
> date_fmt is that date_fmt contains the time zone while d_t_fmt does not.
Yes, I agree that there is no rule, and that probably explains while
there are so many variants. Usually one creates a locale using another
one as an example.
There is at least the case of zh_HK for which t_fmt contains the
time zone, but not d_t_fmt. That looks strange to me.
> So, have we agreed that we can switch date_fmt in en_US to 12 hour
> format?
Personally I am convinced it's the right thing to do.
> Can we do it now despite the freeze period?
I think it's more a question for Siddhesh.
> What do you
> think about my suggestion to use "%r" instead of "%I:%M:%S %p"?
That's more a technical question. I used this form, because the C locale
expands the conversion specifications. But if we can technically use
"%r", it's fine for me, I can update the patch. Can we even use "%c"
directly?
Regards,
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net