public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
* Moving the Japanese Era data out of the locales
@ 2018-03-14 10:44 Florian Weimer
  2018-03-14 16:46 ` Carlos O'Donell
  0 siblings, 1 reply; 2+ messages in thread
From: Florian Weimer @ 2018-03-14 10:44 UTC (permalink / raw)
  To: GNU C Library

We have some level of Japanese Era support in strftime:

$ LC_ALL="ja_JP.utf-8" date +%Ec
平成30年03月14日 10時41分04秒
$ LC_ALL="ja_JP.utf-8" date +%EY
平成30年

(date may actually use a separate copy of the strftime code, but I 
believe it is substantially identical to the glibc implementation.)

There is going to be a transition in 2019 (bug 22964).  Having this in 
locale information is a bit problematic for (some) distributions because 
they have to update glibc for all users, on all release branches, just 
to deliver this change.

Could we synthesize this data from a dedicated file in 
/usr/share/locale, by changing the code in time/era.c?  Then 
distributions can ship this file as part of tzdata, which has a 
different update procedure from glibc.

Thanks,
Florian

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Moving the Japanese Era data out of the locales
  2018-03-14 10:44 Moving the Japanese Era data out of the locales Florian Weimer
@ 2018-03-14 16:46 ` Carlos O'Donell
  0 siblings, 0 replies; 2+ messages in thread
From: Carlos O'Donell @ 2018-03-14 16:46 UTC (permalink / raw)
  To: Florian Weimer, GNU C Library

On 03/14/2018 04:44 AM, Florian Weimer wrote:
> We have some level of Japanese Era support in strftime:
> 
> $ LC_ALL="ja_JP.utf-8" date +%Ec 平成30年03月14日 10時41分04秒 $
> LC_ALL="ja_JP.utf-8" date +%EY 平成30年
> 
> (date may actually use a separate copy of the strftime code, but I
> believe it is substantially identical to the glibc implementation.)
> 
> There is going to be a transition in 2019 (bug 22964).  Having this
> in locale information is a bit problematic for (some) distributions
> because they have to update glibc for all users, on all release
> branches, just to deliver this change.
>
> Could we synthesize this data from a dedicated file in
> /usr/share/locale, by changing the code in time/era.c?  Then
> distributions can ship this file as part of tzdata, which has a
> different update procedure from glibc.
We would have to add net new code to handle this shared resource,
all for what is really a distribution packaging issue.

IMO it would be of higher value to fix the downstream distributions
to ship locales in distinct packages to allow them to be updated
independently of glibc.

This way the problem is solved the next time we have an era change
in 10-80 years.

Cheers,
Carlos.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2018-03-14 16:46 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-03-14 10:44 Moving the Japanese Era data out of the locales Florian Weimer
2018-03-14 16:46 ` Carlos O'Donell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).