public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
* Japanese Era name change and named vs. numbered era date.
@ 2019-01-29 18:33 Carlos O'Donell
  2019-01-29 22:40 ` Rafal Luzynski
  2019-01-30  1:29 ` TAMUKI Shoichi
  0 siblings, 2 replies; 8+ messages in thread
From: Carlos O'Donell @ 2019-01-29 18:33 UTC (permalink / raw)
  To: GNU C Library, TAMUKI Shoichi, Rafal Luzynski

TAMUKI-san,

Is it important to describe the first era year as "å…ƒ" 
versus "1"? Or to allow the user to control this?

This particular issue was raised as a Java issue, where
"Gy" via DateTimeFormatter can print [Era name][Era year],
but does so with [Era year] as a number (arabic numeral).

I don't know how you would implement such an alternative
because it would require enumerating all of the possible
non-arabic-numeral alternatives. It would be an interesting
addition, but I'm not sure it is valuable to do it this way.

Thoughts?

-- 
Cheers,
Carlos.

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

* Re: Japanese Era name change and named vs. numbered era date.
  2019-01-29 18:33 Japanese Era name change and named vs. numbered era date Carlos O'Donell
@ 2019-01-29 22:40 ` Rafal Luzynski
  2019-01-31  8:31   ` Mike FABIAN
  2019-01-30  1:29 ` TAMUKI Shoichi
  1 sibling, 1 reply; 8+ messages in thread
From: Rafal Luzynski @ 2019-01-29 22:40 UTC (permalink / raw)
  To: Carlos O'Donell, GNU C Library, TAMUKI Shoichi

Carlos,

29.01.2019 19:33 Carlos O'Donell <carlos@redhat.com> wrote:
> 
> TAMUKI-san,
> 
> Is it important to describe the first era year as "元" 
> versus "1"? Or to allow the user to control this?
> 
> This particular issue was raised as a Java issue, where
> "Gy" via DateTimeFormatter can print [Era name][Era year],
> but does so with [Era year] as a number (arabic numeral).
> 
> I don't know how you would implement such an alternative
> because it would require enumerating all of the possible
> non-arabic-numeral alternatives. It would be an interesting
> addition, but I'm not sure it is valuable to do it this way.
> 
> Thoughts?

Are you talking about "%Ey" or "%EY"?  In case of "%EY" it is
implemented already.  In case of "%Ey" it may be impossible.

Regards,

Rafal

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

* Re: Japanese Era name change and named vs. numbered era date.
  2019-01-29 18:33 Japanese Era name change and named vs. numbered era date Carlos O'Donell
  2019-01-29 22:40 ` Rafal Luzynski
@ 2019-01-30  1:29 ` TAMUKI Shoichi
  2019-01-30  5:04   ` Carlos O'Donell
  1 sibling, 1 reply; 8+ messages in thread
From: TAMUKI Shoichi @ 2019-01-30  1:29 UTC (permalink / raw)
  To: Carlos O'Donell, Rafal Luzynski, libc-alpha

Hello Carlos-san,

From: Carlos O'Donell <carlos@redhat.com>
Subject: Japanese Era name change and named vs. numbered era date.
Date: Tue, 29 Jan 2019 13:33:26 -0500

> Is it important to describe the first era year as "gan"
> versus "1"? Or to allow the user to control this?

# The above kanji character is correct, but for my mail client, it may
# not be able to be sent correctly, so I replaced it with romaji.

Good point.  It is important to describe the first era year as "gan"
like "Heisei gan nen".  The law and the ordinance promulgated or
enforced in 1989 have the notation "Heisei gan nen".  Although "Heisei
1 nen" is not a mistake, it is not commonly used.

> This particular issue was raised as a Java issue, where
> "Gy" via DateTimeFormatter can print [Era name][Era year],
> but does so with [Era year] as a number (arabic numeral).

As Rafal-san mentioned, it is already implemented in Glibc.  Please
see the attachment of below:

https://www.sourceware.org/ml/libc-alpha/2019-01/msg00554.html

"%EY" is correctly described as above.  In contrast, "%Ey" is
described in Arabic numerals.  It is used when you need to be a
number, such as when calculating the year.  If you dare want to
describe as "Heisei 01 year", you can use "%EC%Ey" instead of "%EY".

> I don't know how you would implement such an alternative
> because it would require enumerating all of the possible
> non-arabic-numeral alternatives. It would be an interesting
> addition, but I'm not sure it is valuable to do it this way.

In ja_JP localedata in Glibc, as in the Heisei example below, the
first year of the era is defined separately from the second year
onwards:

era	"+:2:1990//01//01:+*:<U5E73><U6210>:%EC%Ey<U5E74>";/
	"+:1:1989//01//08:1989//12//31:<U5E73><U6210>:%EC<U5143><U5E74>";/

Regards,
TAMUKI Shoichi

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

* Re: Japanese Era name change and named vs. numbered era date.
  2019-01-30  1:29 ` TAMUKI Shoichi
@ 2019-01-30  5:04   ` Carlos O'Donell
  2019-01-31  0:39     ` TAMUKI Shoichi
  2019-01-31  8:37     ` Mike FABIAN
  0 siblings, 2 replies; 8+ messages in thread
From: Carlos O'Donell @ 2019-01-30  5:04 UTC (permalink / raw)
  To: TAMUKI Shoichi, Rafal Luzynski, libc-alpha

On 1/29/19 8:28 PM, TAMUKI Shoichi wrote:
> In ja_JP localedata in Glibc, as in the Heisei example below, the
> first year of the era is defined separately from the second year
> onwards:
> 
> era	"+:2:1990//01//01:+*:<U5E73><U6210>:%EC%Ey<U5E74>";/
> 	"+:1:1989//01//08:1989//12//31:<U5E73><U6210>:%EC<U5143><U5E74>";/

I'm talking specifically about '%Ey'.

Let me ask my question differently.

Could someone want to output:

"%EC %Ey å¹´"

The equivalnet of %EY, but with spaces, and *also* want %Ey to be
"å…ƒ" in the first year?

I see two choices:

(1) %Ey is always an arabic numeral year-of-era.

(2) %Ey is always an arabic numeral year-of-era, except for the first
    year when it is "å…ƒ".

It sounds like (2) is not that important because %EY already provides
this for you in a compact form.

Java suffers from this problem because they don't have the equivalent
of %EY, they have only 'G' (era name) and 'y' (year-of-era) and their
'y' is always arabic numerals.

https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html

Does that clarify my question?

-- 
Cheers,
Carlos.

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

* Re: Japanese Era name change and named vs. numbered era date.
  2019-01-30  5:04   ` Carlos O'Donell
@ 2019-01-31  0:39     ` TAMUKI Shoichi
  2019-01-31  8:37     ` Mike FABIAN
  1 sibling, 0 replies; 8+ messages in thread
From: TAMUKI Shoichi @ 2019-01-31  0:39 UTC (permalink / raw)
  To: Carlos O'Donell, Rafal Luzynski, libc-alpha

Hello Carlos-san,

From: Carlos O'Donell <carlos@redhat.com>
Subject: Re: Japanese Era name change and named vs. numbered era date.
Date: Wed, 30 Jan 2019 00:03:55 -0500

> > In ja_JP localedata in Glibc, as in the Heisei example below, the
> > first year of the era is defined separately from the second year
> > onwards:
> > 
> > era	"+:2:1990//01//01:+*:<U5E73><U6210>:%EC%Ey<U5E74>";/
> > 	"+:1:1989//01//08:1989//12//31:<U5E73><U6210>:%EC<U5143><U5E74>";/
> 
> I'm talking specifically about '%Ey'.
> 
> Let me ask my question differently.
> 
> Could someone want to output:
> 
> "%EC %Ey nen"
> 
> The equivalnet of %EY, but with spaces, and *also* want %Ey to be
> "gan" in the first year?
> 
> I see two choices:
> 
> (1) %Ey is always an arabic numeral year-of-era.
> 
> (2) %Ey is always an arabic numeral year-of-era, except for the first
>     year when it is "gan".
> 
> It sounds like (2) is not that important because %EY already provides
> this for you in a compact form.

For "%Ey", in order to implement such an alternative, it would be
possible to control (1) and (2) with a certain optional flag, but I
think that hard coding for a specific locale would not be desirable.

> Java suffers from this problem because they don't have the equivalent
> of %EY, they have only 'G' (era name) and 'y' (year-of-era) and their
> 'y' is always arabic numerals.
> 
> https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html

Sorry, I am almost unfamiliar with Java.

According to the following page (sorry, Japanese page), there is
description about the output as "gan nen".

https://qiita.com/yamadamn/items/56e7370bae2ceaec55d5

It was judged not to fix in the past that the Date and Time API can
not output as "gan nen".

https://bugs.openjdk.java.net/browse/JDK-8068571

It is that the output as "gan nen" is to use Mapped-value of
DateTimeFormatterBuilder.

Unfortunately, since it was gradually modified, both parsing and
formatting are enabled in this way since Java 12.

Hopefully, it will be backported to 11, though.

https://bugs.openjdk.java.net/browse/JDK-8042131
https://bugs.openjdk.java.net/browse/JDK-8210633

Regards,
TAMUKI Shoichi

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

* Re: Japanese Era name change and named vs. numbered era date.
  2019-01-29 22:40 ` Rafal Luzynski
@ 2019-01-31  8:31   ` Mike FABIAN
  0 siblings, 0 replies; 8+ messages in thread
From: Mike FABIAN @ 2019-01-31  8:31 UTC (permalink / raw)
  To: Rafal Luzynski; +Cc: Carlos O'Donell, GNU C Library, TAMUKI Shoichi

Rafal Luzynski <digitalfreak@lingonborough.com> さんはかきました:

> Carlos,
>
> 29.01.2019 19:33 Carlos O'Donell <carlos@redhat.com> wrote:
>> 
>> TAMUKI-san,
>> 
>> Is it important to describe the first era year as "å…ƒ" 
>> versus "1"? Or to allow the user to control this?
>> 
>> This particular issue was raised as a Java issue, where
>> "Gy" via DateTimeFormatter can print [Era name][Era year],
>> but does so with [Era year] as a number (arabic numeral).
>> 
>> I don't know how you would implement such an alternative
>> because it would require enumerating all of the possible
>> non-arabic-numeral alternatives. It would be an interesting
>> addition, but I'm not sure it is valuable to do it this way.
>> 
>> Thoughts?
>
> Are you talking about "%Ey" or "%EY"?  In case of "%EY" it is
> implemented already.

Yes:

$ date --date=1989-01-07 +%EY
昭和64年

$ date --date=1989-01-08 +%EY
平成元年

$ date --date=1990-01-07 +%EY
平成2年

> In case of "%Ey" it may be impossible.
>
> Regards,
>
> Rafal

-- 
Mike FABIAN <mfabian@redhat.com>
睡眠不足はいい仕事の敵だ。

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

* Re: Japanese Era name change and named vs. numbered era date.
  2019-01-30  5:04   ` Carlos O'Donell
  2019-01-31  0:39     ` TAMUKI Shoichi
@ 2019-01-31  8:37     ` Mike FABIAN
  2019-01-31 16:51       ` Carlos O'Donell
  1 sibling, 1 reply; 8+ messages in thread
From: Mike FABIAN @ 2019-01-31  8:37 UTC (permalink / raw)
  To: Carlos O'Donell; +Cc: TAMUKI Shoichi, Rafal Luzynski, libc-alpha

Carlos O'Donell <carlos@redhat.com> さんはかきました:

> On 1/29/19 8:28 PM, TAMUKI Shoichi wrote:
>> In ja_JP localedata in Glibc, as in the Heisei example below, the
>> first year of the era is defined separately from the second year
>> onwards:
>> 
>> era	"+:2:1990//01//01:+*:<U5E73><U6210>:%EC%Ey<U5E74>";/
>> 	"+:1:1989//01//08:1989//12//31:<U5E73><U6210>:%EC<U5143><U5E74>";/
>
> I'm talking specifically about '%Ey'.
>
> Let me ask my question differently.
>
> Could someone want to output:
>
> "%EC %Ey å¹´"
>
> The equivalnet of %EY, but with spaces, and *also* want %Ey to be
> "å…ƒ" in the first year?
>
> I see two choices:
>
> (1) %Ey is always an arabic numeral year-of-era.
>
> (2) %Ey is always an arabic numeral year-of-era, except for the first
>     year when it is "å…ƒ".
>
> It sounds like (2) is not that important because %EY already provides
> this for you in a compact form.

I think so too, %EY already does this, it produces 平成元年 for the
first year of the Heisei era. And one would not want to write this with
spaces like 平成 元 年, the spaces look weird in this context anyway.

So I think it is even an advantage that %Ey always produces the number,
it might be helpful if you really want the number for doing some
calculations.

> Java suffers from this problem because they don't have the equivalent
> of %EY, they have only 'G' (era name) and 'y' (year-of-era) and their
> 'y' is always arabic numerals.
>
> https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html
>
> Does that clarify my question?

-- 
Mike FABIAN <mfabian@redhat.com>
睡眠不足はいい仕事の敵だ。

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

* Re: Japanese Era name change and named vs. numbered era date.
  2019-01-31  8:37     ` Mike FABIAN
@ 2019-01-31 16:51       ` Carlos O'Donell
  0 siblings, 0 replies; 8+ messages in thread
From: Carlos O'Donell @ 2019-01-31 16:51 UTC (permalink / raw)
  To: Mike FABIAN; +Cc: TAMUKI Shoichi, Rafal Luzynski, libc-alpha

On 1/31/19 3:37 AM, Mike FABIAN wrote:
> Carlos O'Donell <carlos@redhat.com> さんはかきました:
> 
>> On 1/29/19 8:28 PM, TAMUKI Shoichi wrote:
>>> In ja_JP localedata in Glibc, as in the Heisei example below, the
>>> first year of the era is defined separately from the second year
>>> onwards:
>>>
>>> era	"+:2:1990//01//01:+*:<U5E73><U6210>:%EC%Ey<U5E74>";/
>>> 	"+:1:1989//01//08:1989//12//31:<U5E73><U6210>:%EC<U5143><U5E74>";/
>>
>> I'm talking specifically about '%Ey'.
>>
>> Let me ask my question differently.
>>
>> Could someone want to output:
>>
>> "%EC %Ey å¹´"
>>
>> The equivalnet of %EY, but with spaces, and *also* want %Ey to be
>> "å…ƒ" in the first year?
>>
>> I see two choices:
>>
>> (1) %Ey is always an arabic numeral year-of-era.
>>
>> (2) %Ey is always an arabic numeral year-of-era, except for the first
>>     year when it is "å…ƒ".
>>
>> It sounds like (2) is not that important because %EY already provides
>> this for you in a compact form.
> 
> I think so too, %EY already does this, it produces 平成元年 for the
> first year of the Heisei era. And one would not want to write this with
> spaces like 平成 元 年, the spaces look weird in this context anyway.
> 
> So I think it is even an advantage that %Ey always produces the number,
> it might be helpful if you really want the number for doing some
> calculations.

Perfect. In that case it seems like we have consensus that we don't
need to do anything in glibc for %Ey. I like this result :-)

-- 
Cheers,
Carlos.

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

end of thread, other threads:[~2019-01-31 16:51 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-01-29 18:33 Japanese Era name change and named vs. numbered era date Carlos O'Donell
2019-01-29 22:40 ` Rafal Luzynski
2019-01-31  8:31   ` Mike FABIAN
2019-01-30  1:29 ` TAMUKI Shoichi
2019-01-30  5:04   ` Carlos O'Donell
2019-01-31  0:39     ` TAMUKI Shoichi
2019-01-31  8:37     ` Mike FABIAN
2019-01-31 16:51       ` 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).