Subject: Re: (i18n 51) Alternate calendars [was: Japanese profile]

From: [email-masked] ("[email-masked] (Greger Leijonhufvud, ISC, High Wycombe, U.K.)")
Date: Wed, 9 Jan 91 11:50:44 GMT

In reply to your message of Mon Dec 17 12:42:35 1990
-------
-------

>Long version:
> 1- This really is an internationalisation problem, and not a localisation
>    problem [i.e. not specific to japan]. Countries that have "other"
>    calandar systems (not based on the European solar-based calendar), such
>    as Japan, China, Taiwan, Israel, and Muslim countries, often use the
>    Gregorian calandar as well.

I don't think we can justify %C, if by that you mean "another long format".

---------

>       %c: full date+time (LOCAL calandar)
>       %C: full date+time (LOCAL calandar) (long format)
>       %X [%x]: local representation of full date [time] (LOCAL calandar)
>       %Q [%q]: local representation of full date [time] (GREGORIAN calandar)
>       %k: local representation of full date+time (GREGORIAN calandar)
>       %K: local representation (long format) of full date+time (GREGORIAN calandar)
>          (I don't care what letters are used)

1. I have difficulty justifying another %c: It is up to the locale to
   define what the appropriate date/time representation is; "long format"
   versus "short format" is really irrelevant. Note that the "generic"
   formatters (such as %c %X and %x) are there simply to "replace" asctime,
   %T and %D in a more generalized way.

2. I also cannot understand what %k and %K does that is different from %c
   (or %C).

3. My proposed solution (which I will propose to POSIX.2 Draft 11) is based
   on the concept of field descriptor modifiers, i.e. a letter used with
   the existing field descriptors. These are optional (new text in 2.5
   locale under LC_TIME):

	"It is implementation defined whether the following optional
	keywords shall be recognized. If they are not supported
	but present in a localedef source, they shall be ignored.

	era             Shall be used to define alternate Era's,
			corresponding to the %E field descriptor modifier.
			The format of the operand is undefined, but shall
			support the definition of the %EC and %Ey field
			descriptors, and may also define the "era_year"
			format (%EY).

	era_year        Shall be used to define the the format of the year
			in alternate Era format, corresponding to the %EY
			field descriptor.

	era_d_fmt       Shall be used to define the format of the date in
			alternate Era notation, corresponding to the %Ex
			field descriptor.

	alt_digits      Shall be used to define alternate symbols for digits,
			corresponding to the %O field decriptor
			modifier. The operand shall consist of
			semicolon-separated strings. The first string
			shall be the alternate symbol corresponding with
			zero, the second string the symbol corresponding
			with one, and so on. Up to 100 alternate symbol
			strings may be specified. The %O modifier
			indicates that the string corresponding to the
			value specified via the field descriptor shall
			be used instead of the value."

	This is the rationale:

	As specified under the date command, the field descriptors
	corresponding to the optional keywords consist of a modifier
	followed by a traditional field descriptor (for instance %Ex).
	If the optional keywords are not supported by the
	implementation or are unspecified for the current locale, these
	field descriptors shall be treated as the traditional field
	descriptor. For instance, assume the following keywords:

	alt_digits      0th;1st;2nd;3rd;4th;5th;6th;7th;8th;9th;10th

	era_d_fmt       "The %Od day of %B in %Y~

	d_fmt           "%d.%m.%Y"

	On 7/4/1776, the "%x" field descriptor would result in
	"04.07.1776" and %Ex" would result in "The 4th day of July, 1776",
	while 7/14/1789 would come out as "14.07.1789" and "The 14 day of
	July in 1789". If the "era_d_fmt" keyword is missing, both
	"%x" and "%Ex" will come out as "04.07.1776" and "14.07.1789",
	respectively.

	It can be noted that the above example is for illustrative
	purposes only; the %O modifier is primarily intended to provide
	for Kanji or Hindi digits in date formats.

	While it is clear that an alternate year format is required,
	there is no consensus on the format or the requirements.
	As a result, while these keywords are reserved, the details
	are left unspecified. It is expected that National Standards
	Bodies will provide specifications. "

For the date command, 4.14, pages 314-317, add the following:

	After line 3519, add

	"Certain field descriptors can be preceded by a modifier.
	 The modifier usually indicates a different format or
	 specification for the field descriptor, as specified in
	 the LC_TIME locale description (see 2.5.2.5). If the
	 modifier is not specified or not supported for the locale,
	 the field descriptor value shall be used."
	 is not present."

	After line 3525, add

	"  %C           Century (2 digits)."

	After line 3529, add

	"  %E           Modifier for alternate year notation. Shall
			be followed by either x, y, Y or C.
	  %EC           The name of the alternate year period (or equivalent).
	  %Ex           Alternate date format for country.
	  %Ey           The year only (not the period name).
	  %EY           Full alternate year format."

	After line 3536, add

	" %O            Modifier for alternate numeric symbols. Shall
			be followed by d, e, H, I, m, M, S, U, W or y.
			Indicates that the number specified via the
			field descriptor shall be replaced by an
			alternate numeric symbol. If no alternate
			numeric symbol is available, field descriptor
			value shall be used."

	Add after line 3618:

	"The modifiers support alternate date formats, such as
	 a Japanese Emperor's Era using Kanji digits, rather than
	 the traditional Gregorian date using standard digits.
	 They are specified as modifiers to the traditional field
	 descriptors, so that they can always be used, even if the
	 implementation (or the corrent locale) does not support
	 the modifier. In such a case, the implementation shall
	 treat the modified field descriptor as the field
	 descriptor only."

>     This would remove the problem raised in previous mails about having
>     to know details about the local in order to print the date properly.
>     In the examples given, the application would use
>       %c for the full [Japanese] date+time
>       %C for the full [Japanese] date+time
>       %X for the full [Japanese] date
>       %E for the [Japanese] "year"
>       %Q for the [Japanese] representation of the Gregorian date
>       %Y for the [Japanese] representation of the Gregorian year
>       %k for the [Japanese] representation of the Gregorian date+time
>       %K for the long [Japanese] representation of the Gregorian date+time
>     (replace [Japanese] with [Arabic], [Chinese], [Jewish], or [locale's
>     specific]).

>To resume:
>  1- This is not specific to Japan, it is a general problem applicable to
>     countries that use a non-Gregorian calandar. (I may point out that
>     this is the MAJORITY of people living in the world. But I won't, since
>     someone is sure to state that "the majority" doesn't use computers
>     that much).
>  2- Accessing two different "calendar systems" in a single locale is needed.

>---------------------------------------------------------------------------
>----   Matt Caprile      phone : +33 7639 7752   fax: +33 7639 7518   ----
>----   [email-masked]       -or-         m.caprile@xopen   ----

-------

I think that what I propose does meet the requirements (within the limits
of POSIX), while also retain "backwards compatibility" and portability.

-Greger-