From wk@hpisoe6.cup.hp.com Tue Jan 8 09:40:47 1991 Received: from MCSUN.EU.NET by dkuug.dk via EUnet with SMTP (5.64+/8+bit/IDA-1.2.8) id AA07493; Tue, 8 Jan 91 09:40:47 +0100 Received: by mcsun.EU.net with SMTP; Tue, 8 Jan 91 06:07:52 +0100 Received: from hpisoe6.cup.hp.com by relay.hp.com with SMTP (16.5/15.5+IOS 3.13) id AA05993; Mon, 7 Jan 91 21:06:32 -0800 Received: by hpisoe6.cup.hp.com (15.11/15.5+IOS 3.20+cup+OMrelay) id AA07952; Mon, 7 Jan 91 21:07:29 pst From: Wayne Krone Message-Id: <9101080507.AA07952@hpisoe6.cup.hp.com> Subject: Re: (i18n 55) Re: Alternate calendars To: erik@sra.co.jp Date: Mon, 7 Jan 91 21:07:28 PST Cc: Matt.Caprile@medoc.ec.bull.fr, i18n@dkuug.dk, XoTGinter%xopen@relay.eu.net In-Reply-To: <9012181354.AA26061@noddy.Eng.Sun.COM>; from "Erik M. van der Poel" at Dec 18, 90 10:37 pm Mailer: Elm [revision: 64.9] X-Charset: ASCII X-Char-Esc: 29 I suppose I should say something here since I helped create %E/%N/%o... > > 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. > > I think it's 1911. Can anyone confirm this? ... 1913 -> year 2 of the Republic 1912 -> year 1 of the Republic 1911 -> year 1 before the Republic 1910 -> year 2 before the Republic ... > Anyway, when it is 2011 in the Gregorian calendar, it will be 100 in > Taiwan, so they will "have" a century number. Similarly, in the > Gregorian years 0-99 they "had" a century number, didn't they? > > (By the way, the fact that you said that "The definition of %Y [and > %y] implies..." is not such a good sign; specifications shouldn't > "imply", they should *specify*.) I don't think of %Y and %E as equivalent constructs. %Y is similar to %o. %Y gives the number of the year modulo the Western/Christian era scheme. %o gives the number of the year modulo some era specific to the locale. %Y could be eliminated in favor of the more general %o. The reason we have both is because the two were developed concurrently. When %o was added to HP's product there was no %Y, only the abbreviated %y. During roughly the same time frame X3J11 was is the process of creating %Y for ANSI-C. Since in some date systems giving the value of %o (or %Y) is not sufficient to specify a year, %E was created to add to %o whatever locale specific information is required. In the case of Japanese, this is the name of the era (a variable) and the character NEN (a constant). Since the name of the era can be variable within a given locale, another conversion specifier is needed: %N. > The newspaper prints the year as > > HEISEI 2 NEN (1990 NEN) > > where the "HEISEI" and "NEN" are Japanese Kanji. (I didn't think it > would be wise to try to send JIS X0208 (16-bit Japanese) data via > email. :-) > > Clearly, the "HEISEI 2 NEN" part is %E. And the "1990" part is %Y. > However, there does not seem to be a way of getting the "NEN" after > the "1990" using (the X/Open extended version of) the POSIX.2/D10 > specs. > > We could solve this problem by adding a new format to the LC_TIME > specs -- y_fmt, to be accessed through %z (or whatever), and defined > as "%Y NEN" in the Japanese locale. This is not correct. Most likely the format being used here is application specific (i.e., most Japanese would not use this format) and so should be coded within the application (or the application's message catalog). However, if this was in fact the format generally used then the LC_TIME specs for Japanese should define %E as "%N %o NEN (%Y NEN)". Of course if we were to collapse %o/%Y into a single specifier then this format would be impossible to support from within a single locale. > > In the North African countries, there are usually two (and sometimes 3) > > types of dates printed > > Sometimes 3, eh? So maybe we need to add another letter to the list. > How about %Y, %E and %J? What, 3 is too many? Well, isn't 2 too many, > then? No? Oh, OK, I see: You're trying to define a *reasonable* > standard. :-) Not necessarily. Each date format may be supported by a different locale (or within X/Open a different locale modifier). In the US there are a number of different ways to write the date: January 7, 1991 Jan 7, 1991 7 Jan 91 1/7/91 01/07/91 91/1/7 I don't expect a different "%x" specifier for each one these. Instead I expect %x to return one of the above. If I (or my application) requires a format different from the one supplied then I will modify the locale or create an alternate locale with format I want. Simultaneous support for both %o and %Y (as well as %D/%T versus %x/%X) could be viewed as part of the baggage we have to support given the origins of POSIX or as an indication of the relatively widespread acceptance of the Gregorian calendar. Wayne Krone