Re: [PATCH] en_US: define date_fmt (bug 24046)

[Rafal Luzynski <digitalfreak at lingonborough dot com>]

5.10.2019 01:39 Aurelien Jarno <aurelien@aurel32.net> wrote:
> 
> On 2019-01-05 01:19, Rafal Luzynski wrote:
> [...]
> 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.

I believe this is the case.

> 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.

I was reworking this recently but I have not changed (added/removed)
anything with the time zones.  It has been for long time as it is now.

> > 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.

I'm adding CC: Siddhesh, what do you think?  The patch is not yet
ready but the general idea is to use 12h time format in en_US
instead of 24h.  We have agreed that this is a good idea for US
users, we are only discussing how to implement the format and whether
to do it now or postpone until 2.30.

> > 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?

I think I have not seen "%c" in any locale but I'm not aware of any
technical limitation.  Does it make any difference, like a performance
drop?  Probably yes and probably negligible.  Please test thoroughly
and please post here before committing so other people will be able
to test as well.

Thank you and regards,

Rafal