Subject: Alternate Calandar Systems (again)

From: [email-masked] (Matt.Caprile)
Date: Fri, 18 Jan 91 19:11:06 MET

This never came back to me, so I am sending it again. Sorry if you
get it twice...

Ante-Scriptum : sent to XoTGinter@xopen, [email-masked],
   [email-masked]. (and [email-masked]). Many of the emails
of the discussion were only sent to a sub-set of these lists...

* Date: Wed, 9 Jan 91 11:50:44 GMT
* To: xopen!M.Caprile
* Cc: ism!i18n%dkuug.dk, xopen!XoTGinter
* From: [email-masked] ("Greger Leijonhufvud, ISC, U.K.")
* Subject: (seq 1480) Re: (i18n 51) Alternate calendars [was: Japanese profile]

This originally started out as a "Reply", but ended up being several
hundred lines of included text from many different e-mails. So I Finally
just added a resume' of past comments on the subject at the beginning,
and kept (some of) Greger's comments...

This is a followup to Greger's mail on localedef changes. This is
XoTGinter #1480, UniForum #477, i18n@dkuug #59. I didn't copy the
200 lines into this mail (it will be long enough without it !),
so you may want to look at both at the same time.

This started out of a discussion of the Japanese locale, and a sample
localedef file. I split off the discussion of Date & Time formats
into a seperate thread of discussion. To resume the points raised:

  - Started as a discussion of the "Era" modifier in localedef (& by
    extension, strftime).
  - arguments as to whether it is specific to Japan [localisation] or
    not [internationalisation].
  - someone pointed out that the "era" type of date could (should)
    be part of the "locale's appropriate date (or year) format",
    and not have a set of specifiers for "era" type dates.
    Basically, the %c, %x, %y %Y specifiers should "work properly".
  - "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."
  - Someone else suggested having several locales, one for each
    of the date formats. Examples for Japanese:
	ja_JP,mo	modern Japanese
	ja_JP,tr	traditional Japanese
	ja_JP,go	government Japanese
  - Then I got into the discussion :-( 
    a. This is an I18N problem, not a L10N (localization) problem,
	since many countries (Japan, China, Muslim countries, ...)
	have this sort of problem.
    b. I restated the problem as "having a non-gregorian calendar
	system". (which I could restate as "not having the good
	sense to use the same calendar as those who define
	standards" :-) (I hope that the sarcasm is apparant...)
	The countries that have this "problem" are those that
	do not use the European Gregorian calendar.
    c. I pointed out that those countries that use non-gregorian
	calendars almost always print BOTH dates : the local,
	non-gregorian calendar, and the gregorian calendar.
    d. I pointed out that the current specs are not sufficient
	for locales where two calendar systems are used
	concurrently (there are many of these).
    e. In the the current specs for strftime, it isn't clear if
	the date is gregorian, or "local". This is of course only
	a problem for countries that have two calendars.
    f. I suggested a series of new specifiers for strftime to
	remedy the problem.

So, to start up  discussion again....

First, there are two "issues" (well, two "viewpoints") here:

1. How does a programmer specify dates & times in a portable
   application ?
2. How does one specify information for localedef about date
   and time formats ?

Quick reminder :

      ANSI C has:
	%c locale's appropriate date & time representation
	%x locale's appropriate date representation
	%X locale's appropriate time representation
	%y year without century as a decimal number (00-99)
	%Y year with century as a decimal number

      Proposed X/Open extensions to strftime :
	%E locale's combined Emperor/Era name and year
	%N locale's  Emperor/Era name
	%o locale's  Emperor/Era year

      POSIX.2 Draft 10, Section 2.5.2.5 (localedef's LC_TIME) has:
	d_t_fmt  (the %c specifier)
	d_fmt  (the %x specifier)
	t_fmt  (the %X specifier)
	am_pm  (the AM and PM strings for the locale)(not applicable)

So how does a "stricly conforming application" print out date
and time information for the locale ? Well, using strftime().
And most likely, one of %c, %x or %X. All the other crap is
for BUILDING a date (and/or time) format specific to the
application, which isn't supposed to know anything about the
locale. So it shouldn't be grabbing "day of the week", "24 hour
representation of the time", or "Year" (with or without century).
Or if it does, it isn't the appropriate format for the locale
(it is the application's format, using the correct names of
the week, month, etc. defined in the locale).

Now this poses a problem for countries that print two types of dates
on newspapers, calendars, etc. Both the local (non-gregorian) and
the gregorian calendars are printed. Examples of non-gregorian
calendar systems:

  In Japan, there is a different way of naming the year (based
    on name of emperor, not years since birth of Christ)

  In ROC (Republic of China = Taiwan), there is a different
    way of naming the year (based on years since start of
    Chinese Republic)(which I got wrong, BTW) AND it is a
    lunar calendar (based on revolutions of moon around the
    earth) instead of a solar calendar (based on revolutions
    of earth around the sun). Lunar calendars have the
    annoying property of not synchronising with solar calendars,
    i.e., every lunar year starts on a different "gregorian" day.

  In Muslim countries, the year is the number of "lunar years"
    since the Hejjir (the day that the prophet left Mecca to go
    to Meddine), and it is obviously a lunar calendar.
    (Today is Friday, Jan 11 1991 = Joumoua 25 Joumada Athania 1411).

I respectfully submit that those countries that print two types
of dates, based on two types of calendars, need BOTH available
in a single locale. It is not possible for an application to
print out both types of dates with the current specs. Why ?
  - It isn't clear from the strftime specs what type of calendar
	is printed; non-gregorian, or gregorian ? (Both are valid
	types of dates, and both are used in the country, and
	both a generally printed if either is printed).
  - Impossible for a conforming application to change locales to
	use the "other" date format. What is the locale name that
	is hard-coded into the application ? locale names are
	non-portable.

I have suggested :
* >  %c: full date+time (LOCAL calendar)
* >  %C: full date+time (LOCAL calendar) (long format)
* >  %X [%x]: local representation of full date [time] (LOCAL calendar)
* >  %Q [%q]: local representation of full date [time] (GREGORIAN calendar)
* >  %k: local representation of full date+time (GREGORIAN calendar)
* >  %K: local representation (long format) of full date+time (GREGORIAN calendar)

Greger's comments:

* 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).

The difference between %k and %c is that %c gives the date in the
local, non-gregorian calendar, and %k gives the gregorian calendar.
For example, in Tunisia:

  date "%c" : Joumoua 25 Joumada Athania 1411 19:16:34
  date "%k" : Vendredi, 25 Janvier 1991 19:16:34

I suggested the "long vs. normal" formats as a solution to the prob-
lem of traditional utilities needing two types of formats. Some util-
ities print out "a long date/time" and others a "short date/time".
(And of course each utility uses a different format. Some print one of
the year OR the time, some use abbreviated names of day/month, etc.)
Looking through P.2 Draft 10 I see that this is no longer a problem
for POSIX.2, since the wording for utilities that print out date/time
information has been reworded. So dump the long vs. normal format,
and the time stuff (the hour should be the same independent of locale)
and let's keep :

  %c: full date+time (LOCAL calendar)
  %C: full date+time (GREGORIAN calendar)
  %X: local representation of date (LOCAL calendar)
  %x: local representation of time 
  %Q: local representation of date (GREGORIAN calendar)

notice that the %k and %K formats disappeared. The logic is that
those specifiers (%c, %X) that exist already are SPECIFICALLY
said to refer to the LOCAL calendar, and new specifiers (%C, %Q)
created to specifically refer to the proper representation of the
GREGORIAN calendar. The opposite could just as easily be done.
In some locales (i.e., all those whose local calendar IS
the gregorian calendar) the two will be equal. I will let experts
on Japanese comment on whether or not this is sufficient for Japanese
requirements of the Date, or whether the %E, %N, %o are still needed.
In other words, do applications really need to be able to have access
to the "year/era" information as an entity, or is it OK to just have
the %c and %C. In theory, the application isn't supposed to know that
it is running in Japan, and thus isn't supposed to know whether to
use the %E, %N, %o, or just %Y,%y.

Now let us consider the problem of PORTABLY specifying the information
about local and gregorian calendar systems to localedef. I am not
sure that it is possible in all cases. I liked Greger's suggestion
to use %E as an "introduction to Alternate calendar" information, e.g.
  %EC
  %Ey
  %EY
but it only handles the century year vs. era problem. For those
countries that use a different calendar system, e.g. China &
muslim countries (based on lunar calendar) this doesn't help.
To solve the problem, we need access to (at least) alternate year,
month names, number of day within alternate month, and (possibly)
names of days of the week in alternate (non-gregorian) calendar.
Again, the example of Tunisia:

   Joumoua 25 Joumada Athania 1411  ==  Fri, Jan 11 1991

For the entire year 1411, we have :

   29 Dou El Hijaa 1410		22 July 1990
  --------------- new year --------------- 
   01 Mouharam 1411		23 July 1990
   01 Safar			22 August 1990
   01 Rabia El Aoual		20 September 1990
   01 Rabia El Tani		20 October 1990
   01 Joumada El Aoula		18 November 1990
   01 Joumada Athania		18 December 1990
   01 Rajab			16 January 1991
   01 Shaabane			15 February 1991
   01 Ramadane			16 March 1991
   01 Shoual			15 April 1991
   01 Dou El Kaada		14 May 1991
   01 Dou El Hijaa		13 June 1991
   29 Dou El Hijaa 1411		11 July 1991
  --------------- new year --------------- 
   01 Mouharam	1412		12 July 1991

These dates (the first of each lunar month) may be off by a day,
since it depends on exactly what hour the new moon happens.

A problem is that there is no general correspondence between
dates, or between months in the two calendar systems. An algorithm
(based on astronomical calculations) must be used to calculate
the lunar date; a table cannot be used. So the actual date
and the correspondences cannot be specified in a portable
manner in the localedef file. On the other hand, the names
of the months CAN be specified. In order to access the lunar
information in a strftime call, in order to "build" dates for
non-gregorian calendars as we can for gregorian calendars,
 we would need something like:

 %Eb	abbreviated name of the month (local, non-gregorian calendar)
 %EB	name of the month (local, non-gregorian calendar)
 %Ed	day of the month (local, non-gregorian calendar)
 %Ej	day of the year (local, non-gregorian calendar)
 %Em	month [as a number] (local, non-gregorian calendar)
 %EU	Week number of the year (local, non-gregorian calendar)
 %EW	Week number of the year (local, non-gregorian calendar)
 %Ex	date (local, non-gregorian calendar)
 %Ey	year [as a number] (local, non-gregorian calendar)

(Note that the specs in POSIX.2, when talking about the format
of date/time information output by commands, needs access to
PARTS of the date, such as month name or number, day of week,
etc.)

For the Tunisia example, if the date is:
   Joumoua 25 Joumada Athania 1411  ==  Fri, Jan 11 1991
we would have:

 %Eb	Joumada Athania         %b	Jan
 %EB	Joumada Athania         %B	Janvier
 %Ed	25                      %d	11
 %Ej	173                     %j	11
 %Em	06                       %m	01
 %EU	25                      %U	2
 %EW	25                      %W	2
 %Ex	Joumoua 25 Joumada Athania 1411
                                %x	Vendredi, 11 Janvier 1991
 %Ey	1411                    %y	1991

The solution proposed by Greger will solve the problem for Japan,
but only for Japan. Thus, this isn't internationalisation.

Does anyone have any ideas on this subject ?
Can someone provide examples of alternate calendar information
for Japanese, Chinese, Korean, Thai ? And how the above would
be applicable or not ?

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