From mfc@medoc.ec.bull.fr Mon Dec 17 12:55:06 1990 Received: from inria.inria.fr by dkuug.dk via EUnet with SMTP (5.64+/8+bit/IDA-1.2.8) id AA01903; Mon, 17 Dec 90 12:55:06 +0100 Received: from bull.bull.fr by inria.inria.fr (5.65+/90.0.9) via Fnet-EUnet id AA29348; Mon, 17 Dec 90 12:54:21 +0100 (MET) Received: from ecbull.ec.bull.fr by bull.bull.fr; Mon, 17 Dec 90 12:50:24 +0100 (MET) Received: from medoc by ecbull.ec.bull.fr; Mon, 17 Dec 90 12:54:05 +0100 (MET) Received: by medoc.ec.bull.fr; Mon, 17 Dec 90 12:54:27 +0100 (MET) From: mfc@medoc.ec.bull.fr (Matt.Caprile) Message-Id: <9012171154.AA00817@medoc.ec.bull.fr> Subject: Alternate calendars [was: Japanese profile] To: i18n@dkuug.dk Date: Mon, 17 Dec 90 12:54:23 MET Cc: XoTGinter@xopen.uucp Reply-To: Return-Path: Organization: Bull S.A. (Echirolles) X-Mailer: ELM [version 2.3 PL8] X-Charset: ASCII X-Char-Esc: 29 * > > Of course, the Japanese use both systems, the Western year and the Era * > > year, so that's why we want *two* -- %Y and %E. What I'm trying to say * > > in this message is: Why don't we put the main system (the true local * > > style) in %Y, and put the secondary system in the other one. * > * > Maybe you should have more than one Japanese locale. * * Yes, I like this idea! Instead of introducing things of questionable * generality like %E, we allow (force?) the Japanese (and Koreans, * Taiwanese, etc.) to deal with this locally (localely?). [ ... ] * > I think you have just one (or maybe two) date formats available in * > your locale. There is the d_fmt and d_t_fmt - where the latter * > also includes the time. * * Actually, the user is able to choose from a very large number of * formats for the date. In POSIX.2/D10, the "date" command allows the * use of %H, %M, %S, etc. in the format string: [ ... ] * > Doing programming for Japan depending on the knowledge that one * > date format displays the Era and the other the western date * > seems messy to me. Short resume': 1- This is not specific to Japan, it is a general problem (thus is I18N) 2- Accessing two different "calendar systems" in a single locale is needed. 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. 2- In regards to "We don't need %E since we have %Y" : The definition of %Y [and %y] implies the Gregorian calandar: "the year with[out] century as a decimal number". In Taiwan, the calandar is dated from the "republic" (~1925?) and doesn't HAVE a century number. It is GOOD that this specifically referes to the Gregorian calendar, since it is useful to be able to have BOTH types of dates available ("western" calandar and "other (local)" calandar. Thus I believe it useful to have %Y [%y] mean Gregorian calandar year, and %E (or something else) mean "the local, non-Gregorian calandar year". This would be useful in locales where the year does not start on Jan 1 (and there are quite a few countries where this is the case). 3- This brings up the point of "alternate calendar date formats". It would be useful to be able to print both dates without having to change locales. In most of the North African countries, for example, BOTH types of dates are almost always printed, on calandars, newspapers, etc. Since locale names are non-standardized, how does one portably change locales so as to ONLY change the date format inside of an application? It isn't possible, yet it is rather common in non-European language environments. Example: Today is: 1990.12.17 (in ISO notation). In US : Mon Dec 17 1990 In France: Lundi, 17 Decembre 1990 In Tunisia: Lundi 30 Joumada Eloula 1411 (this is the "French Representation of the Muslim calendar". I didn't think it wise to try and send ISO8859-6 (8bit Arabic) data via mail.) In the North African countries, there are usually two (and sometimes 3) types of dates printed: a. Muslim calandar, in Arabic b. Muslim calandar, in "latin" representation (European characters) c. Gregorian calandar d. (and some countries, [such as Morocco, and parts of Tunisia) the Jewish calandar is also printed) (a) and (b) are just different ways of printing the same information, but they are based on a lunar calandar, which is fundamentally different from the solar-based Gregorian calandar. It is thus impossible to "mix and match" pieces of the locale to build your date. Yet both types of calandar are used, and on the same "document". Changing locales to be able to print both dates is somewhat of a bother, to say the least. (Impossible to do in a portable application). So we need: %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) 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 ----