From greger@iuk Wed Jan 9 14:12:34 1991 Received: from [128.212.16.14] by dkuug.dk via EUnet with SMTP (5.64+/8+bit/IDA-1.2.8) id AA16274; Wed, 9 Jan 91 14:12:34 +0100 Received: by ism.isc.com (Sendmail5.61/1.35) id AA18677; Wed, 9 Jan 91 05:12:32 -0800 Received: from friherr by iuk.isc.com (5.61/smail2.2/11-14-88) id AA02583; Wed, 9 Jan 91 11:11:10 GMT Received: by (5.61/1.35/jcb-s) id AA00617; Wed, 9 Jan 91 11:50:44 GMT Date: Wed, 9 Jan 91 11:50:44 GMT Message-Id: <9101091150.AA00617@> To: M.Caprile@xopen.UUCP Cc: i18n%dkuug.dk@ism, XoTGinter@xopen.UUCP From: greger@ism.isc.com ("greger@ism.isc.com (Greger Leijonhufvud, ISC, High Wycombe, U.K.)") Subject: Re: (i18n 51) Alternate calendars [was: Japanese profile] X-Charset: ASCII X-Char-Esc: 29 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 ---- >---- Matthew.Caprile@ec.bull.fr -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-