Product: Glibc Version: 2.6.3, 2.6.4 OS: Linux Steps to Reproduce: Change LC_TIME to "pl_PL.UTF-8" Reproduce: always Comment: file pl_PL version 1.19 displaying date with roman cipher e.g. (for today) 13-VII-07. Everythig was ok. in ver. 1.18, look at: http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/localedata/locales/pl_PL.diff?r1=1.18&r2=1.19&cvsroot=glibc&f=h Roman cipher aren't polish abbreviation of months ("VII" isn't polish abb. of July).
ISO/IEC TR 14652 abmon Define the abbreviated month names, to be referenced by the %b field descriptor. The operand consists of twelve or thirteen semicolon- separated strings. The first string is the *abbreviated name* of the first month of the year (January), the second the *abbreviated name* of the second month, and so on. In pl_PL ver. 1.19 (Revision 1.12.2.5, fedora-glibc-2_6-4, fedora-glibc-2_6-3) is: I - first month of the year (mon in polish styczeñ) II - second (mon in polish luty) III - third (mon in polish marzec) IV V VI VII VIII IX X XI XII Definition of abmon was correct in previous versions (1.18 or less): sty - first month (from styczeñ) lut - second (from luty) mar - from marzec and so on.
It was broken in bug 3156. My suggestion is to use arabic numerals for months: 01 (Styczeń) 02 (Luty) 03 (Marzec) 04 (Kwiecień) 05 (Maj) 06 (Czerwiec) 07 (Lipiec) 08 (Sierpień) 09 (Wrzesień) 10 (Październik) 11 (Listopad) 12 (Grudzień) Parts of date would be divided by ".", e. g. today would be "14.07.2007". What do you think about it?
You need to dispute BZ#3156. Usually claims that something in locale is incorrect are highly subjective, you need to prove it with standard reference, or if there is a lack thereof, with newspaper references, etc.
Roman numerals are a little bit archaic and used in some publications especially in publications about history and in "elegant" style documents. In Polish standard "Data elements and interchange formats -- Information interchange -- Representation of dates and times" PN-EN 28601:2000 based on ISO 8601 there is no place for Roman numerals. http://www.pkn.pl/index.php?lang=en&m=katalog&a=find&cmd=&pfsymbol=28601&pfsymbolopt=e&pfname=&pfnameopt=e&pfrows=50&submit.x=42&submit.y=5 (again) In ISO/IEC TR 14652: abmon (...) The first string is the *abbreviated name* of the first month of the year (January), the second the *abbreviated name* of the second month, and so on Abbreviated name it's mean abbreviated name not numbers or letters like I, X or V. In Polish dictionaries there are no rules for abbreviating *month names*. I found only one standard PN-85/N-01158 "Abbreviations of words and expressions in bibliographic description" http://www.pkn.pl/index.php?lang=en&m=katalog&a=find&cmd=&pfsymbol=01158&pfsymbolopt=e&pfname=&pfnameopt=e&pfreplace=&pfreplaceopt=e&pfinsert=&pfinsertopt=e&pfics=&pfkt=&pfrows=50&submit.x=36&submit.y=2 This is very old standard (1985) and for bibliographic description so I think that with no rules the best choice is 3-letter names, as it was before. Notation like this are good readable and understoodable for all.
Mr Engelking I need Your opinion about Polish locales and PN-EN 28601:2000 standard.
Most Poles use arabic numerals for months. Parts of date are delimited by ".". Some exemplary sites: http://www.onet.pl (miscellaneous general information) http://www.gpw.pl (Warsaw Stock Exchange) http://gielda.wp.pl (some financial information) http://fundusze.wp.pl (some financial information) http://www.premier.gov.pl (Polish Prime Minister) http://www.msp.gov.pl (Polish Ministry of the Treasury) http://www.mswia.gov.pl (Polish Ministry of Interior and Administration) http://www.pekao.com.pl (some major Polish bank) http://brebank.pl (some major Polish bank) http://www.bdpn.pl (Bieszczady National Park) http://kampinoski-pn.gov.pl (Kampinos National Park) http://www.pngs.pulsar.net.pl (Stolowe Mountains National Park) http://www.pis.org.pl (some political party yet governing in Poland) http://www.sld.pl (some oppositional political party) http://www.us.edu.pl (University of Silesia) http://www.univ.gda.pl (Gdańsk University) http://www.uni.wroc.pl/!nowastrona/ (University of Wrocław) Another solution would be to introduce ISO 8601.
(In reply to comment #4) > Some URLs Are you aware of that you posted links to paid resources?
I am very sorry but with polish standards there are 2 possibilities: to buy or to read in library. I think that this same situation is in other countries (Swiss for example) Displaying in ISO 8601 format is no problem (from man: #date --iso-8601). I can't choose the best links so try with google: sty +lut +mar +pa¼ gov (with Search Polish pages) Try this same with abday pon +wto +¶ro +gru gov Arabic numerals with dot (16.07.2007) is the last instance, but this is only *short numeric date* with month not abbreviated so what with ISO/IEC TR 14652?
There was mistake so once again > sty +lut +mar +pa¼ gov (with Search Polish pages) > Try this same with abday > pon +wto +¶ro +gru gov pon +wto +¶ro +czw gov or combination eg. sty +lut +mar +pon +wto +czw gov
(In reply to comment #8) > I am very sorry but with polish standards there are 2 possibilities: to buy > or to read in library. OK. You expected that some e. g. Czech will go to Poland to search something in a library :) . (In reply to comment #8) > Displaying in ISO 8601 format is no problem (from man: #date --iso-8601). There are many programs other than `date` using date locales (e. g. `svn log`). Most of them don't support customizing of any aspects of date independently from used locale. (In reply to comment #8) > Arabic numerals with dot (16.07.2007) is the last instance, but this is only > *short numeric date* with month not abbreviated so what with ISO/IEC TR > 14652? It is English-specific. It doesn't reflect the fact that some languages (at least almost) never use abbreviated months names.
(In reply to comment #10) > (In reply to comment #8) > > I am very sorry but with polish standards there are 2 possibilities: to buy > > or to read in library. > > OK. You expected that some e. g. Czech will go to Poland to search something > in a library :) . Not me. It's a ....... copyrights. > (In reply to comment #8) > > Arabic numerals with dot (16.07.2007) is the last instance, but this is only > > *short numeric date* with month not abbreviated so what with ISO/IEC TR > > 14652? > > It is English-specific. It doesn't reflect the fact that some languages (at > least almost) never use abbreviated months names. Was English-specific like Whiskey. What is in Poland now You saw in google. Few links, from finance through church to flowers: National Bank of Poland (NBP), Inflation Report 2005 http://www.nbp.pl/Publikacje/o_polityce_pienieznej/raport_o_inflacji/raport_sierpien2005.pdf other document from NBP http://www.nbp.pl/statystyka/Pieniezna_i_bankowa/DWN/miarypieniadza_nowe.xls Ministry of Finance, (MF) http://bip.mf.gov.pl/dokument.php?const=5&dzial=724&id=69871 http://bip.mf.gov.pl/dokument.php?const=5&dzial=53&id=69278 in english version try Ministry of Finance, Public dept, Treasury bonds or Treasury bills and than issuance calendar Wikipedia example: http://pl.wikipedia.org/wiki/Wikipedysta:Yves6 http://pl.wikipedia.org/w/index.php?title=Dyskusja_wikipedysty:Anita_tr&action=history WARSAW UNIVERSITY OF TECHNOLOGY http://www.coi.pw.edu.pl/portal/pls/portal/COI.show_projgantt?d=139 or from google because its .mpp file http://209.85.135.104/search?q=cache:ZYyVbPrbsrUJ:www.coi.pw.edu.pl/portal/pls/portal/COI.show_projgantt%3Fd%3D139+sty+%2Blut+%2Bmar+%2Bpa%C5%BA&hl=en&ct=clnk&cd=61&gl=pl&client=firefox-a Katowice ARCHDIOCESE http://www.katowice.ksm.org.pl/archiwum/2006-10 Ministry of Sport, Permissions for Schooling http://www.msport.gov.pl/download/dokumenty/wykaz_jednostek,_ktore_uzyskaly_zgody_na_szkolenie.pdf Travell Office example http://www.travelplanet.pl/przewodnik/chorwacja/porady-praktyczne/temperatury.html Bloom of Orchid http://www.orchidarium.pl/kwitnienie/rodzaje.php?r=Paphiopedilum
From the other hand. Look how peoples from polish linux communities are trying to workaround Roman numerals: http://zergu.jogger.pl/2007/06/09/polskie-miesiace-w-systemie-eee/ or revert locales to previous version> http://ecik.nonlogic.org/blog/wpisy/31-daty-w-f7 The world Wide Web for example, in the begining it was English-specific (no other characters) and now? Do You think that basic, fundamental locales must be made according to todays national's dictionaries or traditional (before computers) conventions? Today everyone could change displaying of date format to iso 8601 with one command but how to change it to displaying "sty", "lut", "mar", "kwi" without knowing scripts or other programing languages? There is a lot of questions, so maybe Mr. Keld Simonsen will help us?
Your suggestion is against rules of Polish ortography. Abbreviations of normal, single words have such rules: 1. If an abbreviation doesn't contain the last letter of an abbreviated word, it should end with dot. Examples: godz. - godzina tel. - telefon pn. - poniedzialek 2. If an abbreviation contains the last letter of an abbreviated word, it should not end with dot. Examples: nr - numer dr - doktor mgr - magister http://pl.wikipedia.org/wiki/Skrót http://so.pwn.pl/lista.php?co=poniedzia%B3ek http://so.pwn.pl/lista.php?co=wtorek http://so.pwn.pl/lista.php?co=%B6roda http://so.pwn.pl/lista.php?co=czwartek http://so.pwn.pl/lista.php?co=pi%B1tek http://so.pwn.pl/lista.php?co=sobota http://so.pwn.pl/lista.php?co=niedziela 3. Abbreviations must not contain "i" when it is only softening. Example: kwiecien - abbreviation should be "kw." 4. Abbreviations should not divide letters indicating only one sound, e. g. "rz" means English "zh", cz means English "ch" etc. Valid abbreviations of months would be: st. lut. marz. kw. maj cz. lip. srp. wrz. paź. lis. gr. But of course these abbreviations aren't used, so the best solution is to either use arabic numerals or ISO 8601. Remember, that some use of incorrect abbreviations like "sty" doesn't justify introducing them to Polish GLibC locale.
(In reply to comment #13) > Your suggestion is against rules of Polish ortography. > (...) > > 3. Abbreviations must not contain "i" when it is only softening. > Example: > kwiecien - abbreviation should be "kw." > > 4. Abbreviations should not divide letters indicating only one sound, e. > g. "rz" means English "zh", cz means English "ch" etc. > Valid abbreviations of months would be: > st. > lut. > marz. > kw. > maj > cz. > lip. > srp. > wrz. > paź. > lis. > gr. Where did you found "Valid abbreviations of months" because I can't, beside PN-85/N-01158 "Abbreviations of words and expressions in bibliographic description" This ortographical rules are valid only for "marz." and "kw." There is no ortographical problems for "sty.", "cze.", "sie." and "gru." All others are correct 3-letters.
OK. Start again. I think I know where is the problem. 1. I am talking about "system" which must be standarized and compatible all over the world (standards like ISO/IEC TR 14652 was written for). Dots in abmon and abday are only redundant information for nothing. This point of view is good for logs and other low-levels. 2. You are talking about user's interface (word processors, mail programs and so on). Dictionaries and ortographical rules are for this. Here, dots in abmon and abday are important and everything must be made according to country's rules. So, If there is no way now to restore old version of polish locales than we must meet half way and use your proposition for abmon as a 2 digit month abbreviated name e.g. "18.07.2007". But my question about "Valid abbreviations of months" in Poland is still valid.
(In reply to comment #13) By the way: > http://so.pwn.pl/lista.php?co=poniedzia%B3ek pon. > http://so.pwn.pl/lista.php?co=wtorek wt. > http://so.pwn.pl/lista.php?co=%B6roda ¶r > http://so.pwn.pl/lista.php?co=czwartek czw. > http://so.pwn.pl/lista.php?co=pi%B1tek pt. > http://so.pwn.pl/lista.php?co=sobota sob. > http://so.pwn.pl/lista.php?co=niedziela ndz Everything with small letters. This is an example from bug 3156 [calendar of PWN (Polish Scientific Publishers) publisher of the largest and most authoritative Polish-language encyclopedias and dictionaries]. http://kalendarz.pwn.pl/ yes, this same scientific publisher as above but abday different and wihtout dots. Do you feel now why I am fighting for standard? For 3-letter and constant lenght as it was few years in GLibC localedata? I think that past few years was the best practice for ISO/IEC TR 14652 in polish locales.
(In reply to comment #14) > There is no ortographical problems for "sty.", "cze.", "sie." and "gru." All > others are correct 3-letters. http://so.pwn.pl/zasady.php?id=629566 "UWAGI: 1) W języku polskim skrót pojedynczego wyrazu kończy się na spółgłoskę. Do wyjątków należą: a. (= albo), o. (= ojciec) oraz skróty zapożyczone, np. ha (= hektar)." In English: "NOTES: 1) In Polish, an abbreviation of a single word ends with a consonant. The following ones belong to exceptions: a. (=albo) <English "or">, o. (=ojciec) <English "father", used in cases of church orders> and loaned abbreviations, e. g. ha (=hektar) <English "hectare">." (In reply to comment #15) > Dots in abmon and abday are only redundant information for nothing. But they are necessary. > 2. You are talking about user's interface (word processors, mail programs and so > on). Dictionaries and ortographical rules are for this. Here, dots in abmon and > abday are important and everything must be made according to country's rules. Dots are important everywhere when an abbreviation doesn't contain the last letter of an abbreviated word. > But my question about "Valid abbreviations of months" in Poland is still valid. I meant "correct, but unused". (In reply to comment #16) > (In reply to comment #13) > > By the way: > > > http://so.pwn.pl/lista.php?co=poniedzia%B3ek > pon. > > http://so.pwn.pl/lista.php?co=wtorek > wt. > > http://so.pwn.pl/lista.php?co=%B6roda > ¶r > > http://so.pwn.pl/lista.php?co=czwartek > czw. > > http://so.pwn.pl/lista.php?co=pi%B1tek > pt. > > http://so.pwn.pl/lista.php?co=sobota > sob. > > http://so.pwn.pl/lista.php?co=niedziela > ndz > > Everything with small letters. And with dots. > Do you feel now why I am fighting for standard? I am fighting for such a standard which is in accordance with rules of Polish ortography. http://so.pwn.pl/zasady.php?id=629747 lists correct date representations. The following sites also contain some useful rules. http://so.pwn.pl/zasady.php?id=629743 http://so.pwn.pl/zasady.php?id=629574 To summarize: 16 I 2007 - correct, but archaic 16.01.2007 - correct 16 st. 2007 - correct, but never used 16 sty 2007 - incorrect 2007-01-16 - (ISO 8601) semicorrect, unfortunately rather discouraged, allowed when required by data processing systems
I personally prefer ISO 8601, but I think that "16.01.2007" format is the best compromise since it has constant 2-digit length.
(In reply to comment #17) > > But my question about "Valid abbreviations of months" in Poland is still > valid. > > I meant "correct, but unused". But this abbreviations are unused and correct too: st. -> stcz. kw. -> kwc. cz. -> czw. czr. gr. -> grd. So, where did you found that ones as correct? > > > http://so.pwn.pl/lista.php?co=%B6roda > > ¶r > > > http://so.pwn.pl/lista.php?co=niedziela > > ndz > > > > Everything with small letters. > > And with dots. sorry, my mistake > I am fighting for such a standard which is in accordance with rules of Polish > ortography. OK, so read this: http://poradnia.pwn.pl/lista.php?id=8124 [(Abbreviating names of days and month) Language guide of PWN] Jan Grzenia PhD Lecturer, author of this article is from University of Silesia, Faculty of Philology Institute of Polish Language Division of Contemporary Polish Language. http://english.us.edu.pl/?op=kstel_info&id_prac=645&PHPSESSID=4ec4ec29d53f3e52b7be86bc96b1b48e In short: "in computer systems, ortographical rules can be violate e.g. pon., wto., ¶ro., czw., pi±., sob., nie. (this abb. can be with no dots too), but the rules how to do it and for what, must be strictly defined". So, you can realize rules which are strictly defined in ISO/IEC TR 14652 and as it was before GLibC 2.6.3 but: if you choose "today's dictionary" way in place of international standard, don't forget to change abday.
(In reply to comment #19) > it was before GLibC 2.6.3 There's no 2.6.3. The newest version is still 2.6. http://sourceware.org/ml/libc-alpha/2007-07/msg00045.html ftp://ftp.gnu.org/gnu/glibc > if you choose "today's dictionary" way in place of international standard, don't > forget to change abday. I won't forget.
(In reply to comment #20) > (In reply to comment #19) > > it was before GLibC 2.6.3 > > There's no 2.6.3. The newest version is still 2.6. > http://sourceware.org/ml/libc-alpha/2007-07/msg00045.html > ftp://ftp.gnu.org/gnu/glibc I'm sorry for my fault, fedora-glibc-2_6-3 of course (I am using F7)
Created attachment 1922 [details] Compromise patch to pl_PL
(In reply to comment #22) > Created an attachment (id=1922) > Compromise patch to pl_PL Let's see pn., 16.07.2007 17:00:10 CEST wt., 17.07.2007 17:00:10 CEST ¶r., 18.07.2007 17:00:10 CEST czw., 19.07.2007 17:00:10 CEST pt., 20.07.2007 17:00:10 CEST sob., 21.07.2007 17:00:10 CEST ndz., 22.07.2007 17:00:10 CEST Variable abday with dots, numerical abmon. There is no better argument than in comment #19 and I can do nothing more. Now it's your mind and your choice. I am sorry for faults, mistakes and my language of course.
(In reply to comment #23) > Variable abday with dots Maybe we could invent some abbreviations having constant length. Exempli gratia: pon. wtr. śrd. czw. ptk. sob. ndz. wtr., śrd. and ptk. aren't the most widely used abbreviations of these days, but can be occasionally found.
Created attachment 1923 [details] Updated patch to pl_PL
If you want to print months as numbers, changing abmon to numbers is a bad idea. In that case abmon should contain month abbreviations, just use %m instead of %b in the corresponding *_fmt format strings of the locale. Also, not sure if you really should include the dot in day (and month) abbreviations, you can include that dot after %a in the *_fmt format strings.
(In reply to comment #26) > If you want to print months as numbers, changing abmon to numbers is a bad > idea. > In that case abmon should contain month abbreviations, just use %m instead > of %b in the corresponding *_fmt format strings of the locale. Some other programs with non-customizable date format use %b instead of %m. > Also, not sure if you really should include the dot in day (and month) > abbreviations, you can include that dot after %a in the *_fmt format > strings. This dot is the internal part of days abbreviations in Polish.
If some program in a non-customizable way uses %b, it either really wants a month abbreviation (e.g. say in a spreadsheet column you use %b to print month abbreviations, which are even without further context clearly month names; if you use roman numbers or even worse normal decimal representation, it is not clear it is a month number). By setting month abbreviations to decimal representation you force user to use what you decided is right, rather than allowing him to select whatever he wants. Even roman numbers for month are representable in current locales without killing abbreviations - just define alt_digits in the locale to 0, I, II, III, IV, V, VI, ... XCVIII, XCIX and then anyone who wants to use roman numerals for months can use e.g. %e %Om %Y, while %d.%m.%Y can be used with the same locale and %d %b %Y as well.
(In reply to comment #28) > By setting month abbreviations to decimal representation you force user to > use what you decided is right Users still can change these abbreviations locally by editing pl_PL. > If some program in a non-customizable way uses %b, it either really wants a > month abbreviation Or is written by Anglo-centrist programmers who use %b instead of %m because of their not-internationalized habits. They are many already written programs using %b instead of %m without any reason. Using of this patch can be considered as good workaround of these problems. Prosim, apply this patch.
Now, after explanation made by polish language expert (comment #19), we know that previous version of Polish locales was correct in computer systems. Rules defined in ISO/IEC TR 14652 are simple and clear. I don't know where is the problem now. Do you remember Occam's razor (Ockham's razor) rule?
(In reply to comment #27) > This dot is the internal part of days abbreviations in Polish. Yes. In poems, novel, newspapers and so on. Not in computer systems. Read this again: http://poradnia.pwn.pl/lista.php?id=8124 I don't want Shakespeare in my logs.
(In reply to comment #24) > > Maybe we could invent some abbreviations having constant length. > Exempli gratia: > pon. > wtr. > śrd. > czw. > ptk. > sob. > ndz. > > wtr., śrd. and ptk. aren't the most widely used abbreviations of these days, > but can be occasionally found. It makes no sense using occasionally used abbreviations when you can find much more abbreviations which are permitted and accepted in polish language. Good examples are in comment #11 (e.g. Ministry of Finance). This same situation is with abday: http://www.fais.uj.edu.pl/?page=regulamin_fiz/tabela_fakultety&low_vision=on&lang=PL UJ (Jagiellonian University in Krakow). http://www.poloniatransport.pl/rozklady/3a/11/ Polonia - international bus line http://ifa.amu.edu.pl/lll/Kontakty UAM (Adam Mickiewicz University Poznan) http://gimnazjum2.bytow.pl/index.php?module=PostCalendar&func=view&tplview=&viewtype=year&Date=20070707&pc_username=&pc_category=&pc_topic=&print= High School in Bytow In calendars the first letter are capital because of better readability.
(In reply to comment #29) > They are many already written programs using %b instead of %m without any > reason. Using of this patch can be considered as good workaround of these > problems. This patch couldn't be a workaround but permission for messiness. And what with programs where both (%b %m) are used but in different situation? This job will be waste.
(In reply to comment #33) > And what with programs where both (%b %m) are used Which programs exactly?
(In reply to comment #32) > (In reply to comment #24) > > > > Maybe we could invent some abbreviations having constant length. > > Exempli gratia: > > pon. > > wtr. > > śrd. > > czw. > > ptk. > > sob. > > ndz. > > > > wtr., śrd. and ptk. aren't the most widely used abbreviations of these days, > > but can be occasionally found. > > It makes no sense using occasionally used abbreviations when you can find > much more abbreviations which are permitted and accepted in polish language. > Good examples are in comment #11 (e.g. Ministry of Finance). I was talking about abbreviations of days, not months. OK. I think that the following ones are better: pon. / pn. wt. śr. cz. / czw. pt. sob. / sb. ndz. Note that there's no way to exclusively use widely used abbreviations having constant length. Probably abbreviation of one day (ndz.) will have to have different length. Also note that "21.07.2007" date format is very widely used in Poland, so we should use it.
(In reply to comment #34) > (In reply to comment #33) > > And what with programs where both (%b %m) are used > > Which programs exactly? I am not a programmer, so if it is impossible to use both you can write about. I found something like this: http://search.cpan.org/src/YVES/Date-Simple-3.02/lib/Date/Simple.pm http://doxygen.postgresql.org/strftime_8c-source.html http://plone.org/documentation/how-to/change-date-format http://uclibc.org/cgi-bin/viewcvs.cgi/trunk/busybox/date.c?rev=1695&view=markup
(In reply to comment #35) > Also note that "21.07.2007" date format is very widely used in Poland, so we > should use it. And what do you think about RFC 822. http://www.faqs.org/rfcs/rfc822.html We should use standards. (note: other operating system is widely used in Poland, and what you say?) In that way we should use entities or ISO-8859-2 not UTF because it was widely used few years ago.
(In reply to comment #36) > http://search.cpan.org/src/YVES/Date-Simple-3.02/lib/Date/Simple.pm %m is used only in this real code: BEGIN { our $Standard_Format="%Y-%m-%d"; (...) %b and %m are also used in documentation. > http://doxygen.postgresql.org/strftime_8c-source.html %b is used in comments and struct elements. %m is used in struct elements and function static char* _fmt (const char* format, const struct pg_tm* t, char* pt, const char* ptlim, int* warnp). When format contains "D", then pt = _fmt("%m/%d/%y", t, pt, ptlim, warnp);. When format contains "F", then pt = _fmt("%Y-%m-%d", t, pt, ptlim, warnp);. When format contains "v", then pt = _fmt("%e-%b-%Y", t, pt, ptlim, warnp);. If format contains more than letter from set { "D", "F", "V"} , then the latter wins. There's no chance of using both %b and %m. > http://plone.org/documentation/how-to/change-date-format There's no %b. %m is used only in these hints: Another example: We want to change the date format to DD.MM.YYYY (17.01.2005): Change localTimeFormat to %d.%m.%Y Change localLongTimeFormat to %d.%m.%Y %H:%M > http://uclibc.org/cgi-bin/viewcvs.cgi/trunk/busybox/date.c?rev=1695&view=markup Some fragments of code (My comments are inside /* Arfrever's comment: */): char *date_fmt = NULL; if ((date_fmt == NULL) && (optind < argc) && (argv[optind][0] == '+')) date_fmt = &argv[optind][1]; /* Arfrever's comment: If user writes "+some string" e. g. "+%d.%m.%Y" in command line, then date_fmt will be set to this string with "+" skipped. */ if (date_fmt == NULL) { date_fmt = (rfc822 ? (utc ? "%a, %_d %b %Y %H:%M:%S GMT" : "%a, %_d %b %Y %H:%M:%S %z") : "%a %b %e %H:%M:%S %Z %Y"); /* Arfrever's comment: If user doesn't write "+string" in command line and doesn't write "-R", then "%a %b %e %H:%M:%S %Z %Y" is used. If user doesn't write "+string" in command line, but writes "-R" and writes "-u" in command line, then "%a, %_d %b %Y %H:%M:%S GMT" is used. If user doesn't write "+string", writes "-R" and doesn't write "-u" in command line, then "%a, %_d %b %Y %H:%M:%S %z" is used. */ } else if (*date_fmt == '\0') { /* Imitate what GNU 'date' does with NO format string! */ printf("\n"); return EXIT_SUCCESS; } /* Arfrever's comment: See `date +` output. */ /* Handle special conversions */ if (strncmp(date_fmt, "%f", 2) == 0) { date_fmt = "%Y.%m.%d-%H:%M:%S"; } /* Arfrever's comment: If user writes "+string" in command line and this string begins with "%f", then "%Y.%m.%d-%H:%M:%S" is used. See e. g. http://www.cppreference.com/stdstring/strncmp.html */ So it is possible to display both %b and %m, only if user writes both in command line inside +string argument, e. g. +"%b %m".
(In reply to comment #38) > If format contains more than letter from set { "D", "F", "V"} sed -e "s/letter/one letter/" (In reply to comment #36) > I am not a programmer I do see. > so if it is impossible to use both you can write about. Using both probably requires user's stupidity :) . (In reply to comment #37) > And what do you think about RFC 822. > http://www.faqs.org/rfcs/rfc822.html It's English-specific. Also quote: "August 13, 1982" So it's very old. > In that way we should use entities or ISO-8859-2 not UTF because it was > widely used few years ago. "21.07.2007" format is widely used in Poland NOW, not only in the past. UTF-8 is internationalized, while some LC_TIME conventions seem to not be.
(In reply to comment #38) Are you joke? e.g. > > http://plone.org/documentation/how-to/change-date-format > > There's no %b. > %m is used only in these hints: "How to change the default date format in Plone, with some common examples" > Another example: We want to change the date format to DD.MM.YYYY (17.01.2005): > Change localTimeFormat to %d.%m.%Y > Change localLongTimeFormat to %d.%m.%Y %H:%M "A full list of all the available format options can be found in the..." > So it is possible to display both %b and %m, only if user writes both in > command line inside +string argument, e. g. +"%b %m". You mean both together, but I said in comment #33, "where both (%b %m) are used but in different situation" For example when someone want to change month displaying from numerals to abbr. name. With your patch he/she can change from numerals to numerals (%m to %b)
(In reply to comment #39) > > And what do you think about RFC 822. > > http://www.faqs.org/rfcs/rfc822.html > > It's English-specific. Also quote: > "August 13, 1982" > So it's very old. Do you mean RFC's are English-specific? Do you mean RFC 822 are invalid? Which one replace it? From the other hand, my processor are also English-specific. Do you want to localize the instruction set? And my harddisk are English-centrist too (below operating system). > "21.07.2007" format is widely used in Poland NOW, not only in the past. In the past there was Roman numerals. Arabic numerals begins when primitive calculators was build. Now computers are more power than we can use letters in month name. > UTF-8 is internationalized, while some LC_TIME conventions seem to not be. And with a little help from you - never be.
To summarize: 1. Abday: pn. pon. wt. ¶r. czw. pt. sob. ndz. Correct with general Polish ortographical rules. Rules for all purposes. Dots are important especially when abbr. is in the middle of the sentence or with no time context. Variable lenght, no accordance to standards. pon. wtr. ¶rd. czw. ptk. sob. ndz. Correct with general Polish ortographical rules. Rules for all purposes. Dots are important especially when abbr. is in the middle of the sentence or with no time context. Constant lenght, accordance to ISO/IEC TR 14652. New abbr. "wtr.", "¶rd.", "ptk." not really used in Poland pon wto ¶ro czw pi± sob nie Correct with Polish ortographical rules for abbr. used in computer systems. Dots aren't necessary with that rules or in the time context. Constant lenght, accordance to standards. Used in Poland on variety arenas. 2. Abmon 22 VII 2007 - correct, but archaic 22.07.2007 - correct, but violates standards, unusable %b (%b=%m) 22 lip 2007 - correct in computer systems, accordance with standards So my proposition is: pon, 16 lip 2007 17:00:10 CEST wto, 17 lip 2007 17:00:10 CEST ¶ro, 18 lip 2007 17:00:10 CEST czw, 19 lip 2007 17:00:10 CEST pi±, 20 lip 2007 17:00:10 CEST sob, 21 lip 2007 17:00:10 CEST nie, 22 lip 2007 17:00:10 CEST
(In reply to comment #40) > You mean both together, but I said in comment #33, "where both (%b %m) are > used but in different situation" I didn't see "in different situation", but %b was created, because the situation, when %b would be used, was invented by English people expecting such months abbreviations to be used. Months literal abbreviations aren't normally used in Polish, so in Polish it is legal to equate %b to %m. > For example when someone want to change month displaying from numerals to > abbr. name. English people and maybe some others (not Poles) would want to do it. > With your patch he/she can change from numerals to numerals (%m to %b) He/she can change this file (pl_PL) locally. (In reply to comment #41) > Do you mean RFC 822 are invalid? It is valid for English. > > UTF-8 is internationalized, while some LC_TIME conventions seem to not be. > > And with a little help from you - never be. I accidentally used wrong word. sed -e "s/internationalized/appropriate to all languages/" (In reply to comment #42) > So my proposition is: > > pon, 16 lip 2007 17:00:10 CEST > wto, 17 lip 2007 17:00:10 CEST > ¶ro, 18 lip 2007 17:00:10 CEST > czw, 19 lip 2007 17:00:10 CEST > pi±, 20 lip 2007 17:00:10 CEST > sob, 21 lip 2007 17:00:10 CEST > nie, 22 lip 2007 17:00:10 CEST My proposition is: pn., 16.07.2007 17:00:10 CEST wt., 17.07.2007 17:00:10 CEST śr., 18.07.2007 17:00:10 CEST cz., 19.07.2007 17:00:10 CEST pt., 20.07.2007 17:00:10 CEST sb., 21.07.2007 17:00:10 CEST ndz., 22.07.2007 17:00:10 CEST Currently implemented date format has variable length, so small variability can be retained. It is the best compromise, because it has format with as most constant length as it can have with accordance with TRUE rules of Polish ortography.
(In reply to comment #5) > Mr Engelking I need Your opinion about Polish locales Maybe Piotr Engelking has holidays, so we could wait for his opinion.
Created attachment 1927 [details] Updated compromise patch to pl_PL
(In reply to comment #43) > Months literal abbreviations aren't normally used in Polish, so in Polish it > is legal to equate %b to %m. Nowhere is legal to strip functionality. Maybe on Cuba or Bialorus. This abbreviations *are* normally used in Poland (comment #11) > > For example when someone want to change month displaying from numerals to > > abbr. name. > > English people and maybe some others (not Poles) would want to do it. Do you want to forbid them? They want, and they are using it. Look on examples in comment #11, please. > > With your patch he/she can change from numerals to numerals (%m to %b) > > He/she can change this file (pl_PL) locally. Look at comment #12. Do you think it will be easy for ordinary user? > (In reply to comment #41) > > Do you mean RFC 822 are invalid? > > It is valid for English. Great joke. Try to read it. This is not about message body and there is nothing about English. > Currently implemented date format has variable length, so small variability > can be retained. It is the best compromise, because it has format with as most > constant length as it can have with accordance with TRUE rules of Polish > ortography. Do you suggest that paper rules are TRUE, but specialist from University of Silesia, Faculty of Philology Institute of Polish Language Division of Contemporary Polish Language (comment #19) are wrong? Do you thing that we, in Poland, are living in huts, and treating language rules as holy? Language is living and changing all the time. On papers we have ancient rules. So Mr.Jan Grzenia PhD writes about today (and tomorrow) not yesterday like "paper" rules.
(In reply to comment #44) > Maybe Piotr Engelking has holidays, so we could wait for his opinion. From 2007-07-10, probably. Look at closed bug 3156
(In reply to comment #46) > > Currently implemented date format has variable length, so small > > variability can be retained. (...) > > Do you suggest that (...) specialist (...) are wrong? My comment was primarily focused on date constancy / variability. This mentioned specialist didn't say that variability is wrong. > Language is (...) changing all the time. So why date length can't be changing all the time?
(In reply to comment #10) > (In reply to comment #8) > It is English-specific. It doesn't reflect the fact that some languages (at > least almost) never use abbreviated months names. What do you mean "at least almost"? few examples from locale: Norwegian language locale for Norway nb_NO abday - 3 first letters abmon - 3 first letters Danish language locale for Denmark da_DK abday - 3 first letters abmon - 3 first letters Serbian Language Locale for Serbia sr_RS abday - 3 first letters abmon - 3 first letters Spanish Language Locale for Spain es_ES abday - 3 first letters abmon - 3 first letters German Language Locale for Austria de_AT abday - 3 first letters abmon - 3 first letters German Language Locale for Switzerland de_CH abday - 3 first letters abmon - 3 first letters French Language Locale for France fr_FR abday - 3 first letters abmon - 3 first letters Italian Language Locale for Italy it_IT abday - 3 first letters abmon - 3 first letters Icelandic Language Locale for Iceland is_IS abday - 3 first letters abmon - 3 first letters Enough?
(In reply to comment #48) > > > Language is (...) changing all the time. > > So why date length can't be changing all the time? It can of course but isn't good enough for standards and for computer systems. It is good enough for poems, mewspapers or novels. Another problem is with polish documentations and manuals (e.g. man for "date"). Do you think it's good idea to make different manuals for one command? Maybe you want someone to add in polish version of "date" man: "%b - Arfrever.FTA@GMail.Com said - this is legally not to use this parameter in Poland. This parameter is not for you Poles it's only for English people"
In ISO/IEC TR 14652 there is a very good mechanizm, languages independent. Why you want to spoil it? and make a lot of unexpected consequences? in programist's job, documentations, manuals or bug 4773 for example?
I wasn't the first: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242296
(In reply to comment #48) > My comment was primarily focused on date constancy / variability. This > mentioned specialist didn't say that variability is wrong. Because it isn't wrong! It's only incompatible with standards. He know nothing about ISO/IEC TR 14652 and you everything. Remember, Occam's razor: "All things being equal, the simplest solution tends to be the best one." Simplest solution is to use mechanism described in ISO/IEC TR 14652 and searching for other solutions only for countries where this abbreviations are forbidden.
(In reply to comment #49) > (In reply to comment #10) > > It is English-specific. It doesn't reflect the fact that some languages > > (at least almost) never use abbreviated months names. > > What do you mean "at least almost"? http://ling.pl/least http://ling.pl/almost "To jest specyficzne dla jezyka angielskiego. To nie odzwierciedla faktu, ze niektore jezyki (przynajmniej prawie) nigdy nie uzywaja skroconych nazw miesiecy." (In reply to comment #50) > Another problem is with polish documentations and manuals (e.g. man > for "date"). > Do you think it's good idea to make different manuals for one command? The following patch is sufficient: --- date.1 +++ date.1 @@ -62,7 +62,7 @@ lokalna pełna nazwa dnia tygodnia (poniedziałek...niedziela) .TP %b -lokalny skrót nazwy miesiąca (sty...gru) +lokalny skrót nazwy miesiąca (01...12) .TP %B lokalna pełna nazwa miesiąca (styczeń...grudzień) (In reply to comment #53) > Simplest solution is to use mechanism described in ISO/IEC TR 14652 And adjust it to Polish reality.
What is with nabble? Am I really reporter of bug 3156? or maybe Mr. Engelking? http://www.nabble.com/-Bug-localedata-3156--New:-LC_TIME-for-pl_PL-doesn't-match-standard-usage-t2193941.html
(In reply to comment #55) > What is with nabble? nabble.com is completely broken :) . http://www.nabble.com/Sourceware---libc-locales-f12203.html
Nobody care about nabble? OK. But who change Mr. Engelking account to my address? http://www.nabble.com/user/UserProfile.jtp?user=97042
http://bugs.archlinux.org/task/7444 http://permalink.gmane.org/gmane.linux.debian.devel.bugs.general/279616
(In reply to comment #54) > (In reply to comment #53) > > Simplest solution is to use mechanism described in ISO/IEC TR 14652 > > And adjust it to Polish reality. Let's summarize this two solutions: LC_TIME in Polish localisation file A. Your proposition accordance: - ortographical rules: YES, but which version is the best? (patch1, patch2, patch3, bug 4773) - ISO/IEC TR 14652: NO (variable lenght) changes needed: YES to documentations, manuals, programs usability: no abbreviated month name (%b=%m) B. My proposition accordance - ortographical rules: YES (3 first letters of day and month with no dots) - ISO/IEC TR 14652: YES (constant lenght) changes needed: NO usability: YES full In my opinion B. is simplest solution than A.
Most countries in Europe (as in comment #49) are using 3-first letter abbreviations for abday and abmon. The next few are using this for abmon. So choice what to do, is easy.
My question from comment #56 and comment #57 is still valid: http://www.nabble.com/forum/Search.jtp;jsessionid=13iek953eyezg?userPosts=n&user=97042&query=posts+by+%27inkerman42+at+gmail+dot+com%27&daterange=0&startdate=1182755166590&enddate=1185347166590 Can owner change account email address?
(In reply to comment #59) > which version is the best? (patch1, patch2, patch3, bug 4773) This patch which is not marked obsolete.
Created attachment 1935 [details] 3 letters abmon and abday Maybe this patch. This is my first one.
(In reply to comment #63) > Created an attachment (id=1935) > 3 letters abmon and abday > > Maybe this patch. This is my first one. This patch looks awfully. The newest mine is significantly better.
(In reply to comment #64) > This patch looks awfully. It's difference between version 1.18 and 1.19 of pl_PL, only.
(In reply to comment #65) > It's difference between version 1.18 and 1.19 of pl_PL, only. If version 1.18 was good, then it wouldn't be changed. Actually it was changed, but apparently not ideally and my patch tries to fix the situation.
(In reply to comment #66) > If version 1.18 was good, then it wouldn't be changed. Interesting logic. * OK. Let's try to summarize problem once again. 1. We know now, that bug 3156 was misunderstanding, so 2. you should revert the last known good version (with no bug reports) of pl_PL (1.18 or 1.17 with changes in LC_MONETARY) 3. After this, you can open your own bug report "Incorrect date and month abbreviations in Polish locales" for example, or 4. maybe somebody else will open new bug report.
Created attachment 1940 [details] Polish locales - MC What we talking about - MC
Created attachment 1941 [details] Polish locales - "ls -l" What we talking about 2 Addendum to comment #1
(In reply to comment #68 and comment #69) They would like good with my patch aplied. These comments are consistent with comment 66.
(In reply to comment #70) > These comments are consistent with > comment 66. ... or with comment #67 point 1 And this is a reason to realize next points ASAP. Now it is 3rd month of using "changed not ideally" version.
Created attachment 1945 [details] seaudit view This is seaudit from setools-gui. With your patch, who will know where is day or month? Do you know more examples like this? Or want me to searching for?
Explanation to attachment (id=1945) and comment #72 With decimal notation of abmon, seaudit will be displaying Date as: * 08.03 21:23;24 2007 In Poland it's mean "eighth of march". With my patch (or earlier versions of abmon) it will be: * sie 03 21:23;24 2007 This notation is correct and mean "third of august". I think, there is a lot of programs "english-specific" which never be translated or localised. Decimal notation of abmon will be the big mislead and will be the cause to mistake for users with Polish LC_TIME
Once again, because of language mistakes. Explanation to attachment (id=1945) and comment #72 With arbic numerals as month abbreviation names, seaudit will be displaying Date as: * 08.03 21:23:24 2007 In Poland it's mean "eighth of march". With my patch (or with earlier versions of abmon) it will be: * sie 03 21:23:24 2007 This notation is correct and mean "third of august". I think, there is a lot of programs "english-specific" which never be translated or localised. In such situations, arabic numerals as month abbreviation names could be the big mislead about real date.
(In reply to comment #74) > Once again, because of language mistakes. See: > With arbic numerals We shouldn't care about unmaintainted, obsolete, broken packages. (There's no "seaudit" in my distribution.)
(In reply to comment #75) > (There's no "seaudit" in my distribution.) http://elibrary.fultus.com/technical/index.jsp?topic=/com.fultus.redhat.elinux4/manuals/rhel-selg-en-4/rhlcommon-section-0105.html https://rhn.redhat.com/errata/RHBA-2007-0192.html http://ftp.wwc.edu/pub/isos/mounted-ISOS/redhat/rhel/5/rhel-5-client-x86_64-disc4/Client/ http://selinuxnews.org/wp/index.php/2007/08/03/setools-33-released/ http://oss.tresys.com/projects/setools http://oss.tresys.com/projects/setools/timeline
Created attachment 1948 [details] ScrollKeeper Log Very good example from ScrollKeeper log. This is upgrade from FC6 to Fedora 7 With patch proposed by you it will be: * 06.03 It's mean sixth of march.
Because few links from comment #76 are dead now, another few links about setools (with seaudit): http://d01.dyndns.org/sharel/img/rhel5-i386/disc4/Server/ http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/Deployment_Guide-en-US/ch-selinux.html http://www.nsa.gov/selinux/list-archive/0702/19215.cfm http://selinuxnews.org/wp/?s=setools It is maintained and very useful.
And the last example, I think. Look at attachment (id=1941). Do you think that after your patch "ls" output will change date order? or it will be month.date (e.g. 08.01 6:24) still? With arabic numerals for months will be a lot of problems too, but different kind than with Roman numerals.
There is an apparent misconception on the purpose of the locale-specific time formats here. They aren't supposed to be an exact copy of the C locale, but to implement the existing natural language conventions. Please refer to the rationale for the C standard (complete with using Roman numerals in date abbreviations, by the way). Depending on unreasonable assumptions about a locale (endianness of the date format, format widths, existence of am_pm, etc.) is simply a bug. Such a bug should usually be trivial to fix, with an immediate benefit to users of other locales, as well.
(In reply to comment #80) > but to implement the existing natural language conventions. "Though the exact definition is debatable, natural language is often contrasted with artificial or constructed languages such as Esperanto." (...) "Linguists have an incomplete understanding of all aspects of the rules underlying natural languages" (Not only linguists, I think) (...) "While grammarians, writers of dictionaries, and language policy-makers all have a certain influence on the evolution of language, their ability to influence what people think they 'ought' to say is distinct from what people actually say" * http://en.wikipedia.org/wiki/Natural_language *The existing* it's mean used today (links at comment #11), not yesterday. 1. Roman numerals for months aren't today's Polish language conventions. Beside not many publishers nobody using it. 2. For hand-written texts arabic numerals are standard because of easy writting. 3. Words without dots and 3 letter abbreviations are still natural Polish language. It is correct and approved in computer systems (comment #19). I hope we are talking about Polish natural language in computer systems? This is not alt.pl.poetry group?
(In reply to comment #80) > There is an apparent misconception on the purpose of the locale-specific > time formats here. They aren't supposed to be an exact copy of the C locale, > but to implement the existing natural language conventions. You're right. > Depending on unreasonable assumptions about a locale (endianness of the date > format, format widths, existence of am_pm, etc.) is simply a bug. You're right. (In reply to comment #81) > 1. Roman numerals for months aren't today's Polish language conventions. > Beside not many publishers nobody using it. I agree that they're too archaic. > 2. For hand-written texts arabic numerals are standard because of easy writting. They're standard for ALL texts. > 3. Words without dots and 3 letter abbreviations are still natural Polish > language. No. They're incorrect.
(In reply to comment #82) > > 3. Words without dots and 3 letter abbreviations are still natural Polish > > language. > > No. They're incorrect. Do you forget Comment #19 ? http://poradnia.pwn.pl/lista.php?id=8124 [(Abbreviating names of days and month) Language guide of PWN] Jan Grzenia PhD Lecturer, author of this article is from University of Silesia, Faculty of Philology Institute of Polish Language Division of Contemporary Polish Language. http://english.us.edu.pl/?op=kstel_info&id_prac=645&PHPSESSID=4ec4ec29d53f3e52b7be86bc96b1b48e In short: "in computer systems, ortographical rules can be violate e.g. pon., wto., ¶ro., czw., pi±., sob., nie. (this abb. can be with no dots too), but the rules how to do it and for what, must be strictly defined". So, you can realize rules which are strictly defined in ISO/IEC TR 14652 and as it was before" fedora-glibc-2_6-3
(In reply to comment #83) > Do you forget Comment #19 ? I never said that comment #19 was valid or correct. > you can realize rules which are strictly defined in ISO/IEC TR 14652 Such rules should be realized with adjustment to normal (not violated) rules of Polish ortography.
(In reply to comment #84) > I never said that comment #19 was valid or correct. Yes, I know. But you're not Polish language specialist. Jan Grzenia is. Are you really sure your skills in ortography are higher? Why not change date displaying in Wikipedia first if you think that it is incorrect? http://pl.wikipedia.org/wiki/Dyskusja_wikipedysty:Arfrever
(In reply to comment #85) > Why not change date displaying in Wikipedia first if you think that it is > incorrect? I'm not Wikipedia administrator, so I can't perform this useful change.
(In reply to comment #84) > Such rules should be realized with adjustment to normal (not violated) rules > of Polish ortography. There must be rules which shouldn't violate computer systems and programs too. If you will change all programs to displaying correct date order there will be no problem using arabic numerals two times (one for day an second for month).
(In reply to comment #86) > I'm not Wikipedia administrator, so I can't perform this useful change. Are you tried to dispute with them like now with me? What was the answer? Maybe you know why they don't want to change and using "correct" date displaying?
(In reply to comment #87) > If you will change all programs to displaying correct date order there will > be no problem using arabic numerals two times (one for day an second for > month). I can try to do it. http://subversion.tigris.org/issues/show_bug.cgi?id=2849 (In reply to comment #88) > > I'm not Wikipedia administrator, so I can't perform this useful change. > > Are you tried to dispute with them like now with me? I didn't have time.
(In reply to comment #89) > > If you will change all programs to displaying correct date order there will > > be no problem using arabic numerals two times (one for day an second for > > month). > > I can try to do it. When you finish with all programs, there will be a good time for renew dispute about arabic numerals in Polish date, I think.
(In reply to comment #89) > > > I'm not Wikipedia administrator, so I can't perform this useful change. > > > > Are you tried to dispute with them like now with me? > > I didn't have time. Time? or enough administrator privileges to force your conception?
(In reply to comment #90) > When you finish with all programs, there will be a good time for renew > dispute about arabic numerals in Polish date There is good time now. (In reply to comment #91) > Time? or enough administrator privileges to force your conception? Time. Maybe it's internal MediaWiki bug. If you start filing bug reports about date formats in miscellaneous programs, you will be more helpful for us.
Yet another argument, why people choosing 3 letters month and day abbreviation formats (like Polish Wikipedia for example). * N. 12 VIII 2007 Every one must care is it "VII" or "VIII" in date, "N." is abnormal abbreviation (beside commercial calendar producer) * pn., 06.08.2007 Is it sixth of August or eight of July? "pn.," Two letters and two punctuation marks. On my clock and watch. Isn't beautiful? * wto 07 sie 2007 This format is user-friendly and good readable. It is no problem with understanding which day and month is. It is programs-friendly and good for analyze. It can be in different orders (in different programs): * sie 07 wto 2007, 2007 sie 07 wto, 07 sie wto 2007 and so on. And every one in Poland will correct understand this date. And all programs can do correct interpretation. This is for what standards are.
(In reply to comment #92) > If you start filing bug reports about date formats in miscellaneous programs, > you will be more helpful for us. I like good jokes, but this about Sisyphus is pitiful. Sorry, I'm not so pride to know all programs. If you restore correct polish abday an abmon as it was before bug 3156 than you will have more time for other bugs and will need less helpers.
(In reply to comment #93) * pn., 06.08.2007 Is it sixth of August or eight of June? (not July of course)
(In reply to comment #93) > * wto 07 sie 2007 > This format is user-friendly and good readable. It is no problem with > understanding which day and month is. It is programs-friendly and good for analyze. > It can be in different orders (in different programs): > * sie 07 wto 2007, 2007 sie 07 wto, 07 sie wto 2007 and so on. And every one in > Poland will correct understand this date. And all programs can do correct > interpretation. > I agree totally with Your arguments. Most of users are accustomed to and understand 3 letter abbreviations. This is completely readable and not against rules as expertises above say. If this was so big mistake this would be changed long ago. The attached screenshots show exactly how bad it looks and how hard to read are these roman capitals. Not mentioning problems with all scripts, applications etc... This should be reverted to previous state.
(In reply to comment #96) > Most of users (...) understand 3 letter abbreviations. Understanding of something doesn't justify introducing this something. > This is (...) not against rules as expertises above say. You misinterpreted miscellaneous information. > This should be reverted to previous state. No. The best solution is to use "22.08.2007" format.
(In reply to comment #97) > The best solution is to use "22.08.2007" format. You can use it with %m, if you like it. In this bug report we are talking about incorrect abmon. It's mean that %b can't be roman numerals or equal to %m. Two different parameters with one value - this will be a big bug. Read this discussion carefully and look at attached screenshots.
(In reply to comment #98) > %b can't be roman numerals or equal to %m. It can be.
Using arabic numbers for both month and day *is* a bad idea. Believe me, enough confusion is caused between American and British date formats. August 26th, 2007 and 26th August 2007 can be understood easily, but if you use only numbers for a date before the 12th day of the month, the fun begins. Vide 02032007: is it British? Or American? Is it 2nd March, or February 2nd? So please, at least try not to introduce additional confusion and don't make the month abbreviation a number. By the way, for the language purists, I think that the bigger problem is that the month number do not support declension, and are shown as 26 sierpieñ, not 26 sierpnia, as they should be.
I meant February 3rd, of course.
(In reply to comment #100) > Vide 02032007: is it British? Or American? Is it 2nd March, or February 2nd? Poles aren't so divided in case of date format as anglophones are. > By the way, for the language purists, I think that the bigger problem is > that the month number do not support declension, and are shown as 26 > sierpień, not 26 sierpnia, as they should be. So open a new bug report for that issue.
(In reply to comment #102) > (In reply to comment #100) > > Vide 02032007: is it British? Or American? Is it 2nd March, or February 2nd? > > Poles aren't so divided in case of date format as anglophones are. > Luckily we are not. The endianess of our date goes in par with the Brits, it looks like the Europeans just stick together. My point is, that by changing the abdate to arabic numerals we will only introduce additional confusion. The date 02.03.2007 is perfectly unambiguous in written texts where everything sticks to Polish rules. In IT, however, where the large part of the engineers are American, and can unintentionally force the endianess of the date, it will only lead to confusion. This has been illustrated by the scrollkeeper log posted above. I am not saying it is wrong, in my opinion it is just not the optimal way of handling the month abbreviation.
(In reply to comment #103) > In IT, however, where the large part of the engineers are American, and can > unintentionally force the endianess of the date So we should loudly criticize them for their thoughtlessness. > This has been illustrated by the scrollkeeper log posted above. Scrollkeeper is unmaintained, so unfixable. > I am not saying it is wrong, in my opinion it is just not the optimal way of > handling the month abbreviation. My suggestion is to fix all packages to use localized date format. Do you know, how to use xgettext, msgfmt, msgunfmt, msgmerge and gettext?
IMHO comment #19 contains the definitive answer here and pl_PL change should be reverted. It was good the way it was before. There was no compelling reason to change it. Bug 3156 needs to be revisited and reverted.
(In reply to comment #105) > pl_PL change should be reverted. It was good the way it was before. No. > There was no compelling reason to change it. No. > Bug 3156 needs to be revisited and reverted. No.
OK, let me get this straight. If you feel that the proper way is to fix all the packages to use the proper date format, so be it. But the way such problems should be addressed is first fixing the packages, then changing the date. Not the other way round, causing confusion all over the place.
(In reply to comment #107) > OK, let me get this straight. If you feel that the proper way is to fix all > the packages to use the proper date format, so be it. But the way such > problems should be addressed is first fixing the packages, then changing the > date. The number of packages to fix is fortunately relatively small. > Not the other way round, causing confusion all over the place. There is currently no confusion. Everybody please list still maintained packages which may need to be fixed. I'm listing: Subversion Coreutils - `ls -l` SETools MC
(In reply to comment #106) > (In reply to comment #105) > > pl_PL change should be reverted. It was good the way it was before. > > No. > > > There was no compelling reason to change it. > > No. > > > Bug 3156 needs to be revisited and reverted. > > No. And what makes you qualified to decide? You still haven't addressed the points raised in comment #19. It's been pointed out to you, that these abbreviations ARE in common use (comment #11) and - even though against the rules for written orthography - are ACCEPTABLE for use in computer systems (http://so.pwn.pl/zasady.php?id=629747), as long as they're well-defined, which is an opinion backed by language experts (http://poradnia.pwn.pl/lista.php?id=8124). Why are you ignoring these FACTS?
(In reply to comment #109) > You still haven't addressed the points raised in comment #19. There are no valid points raised in comment #19. > It's been pointed out to you, that these abbreviations ARE in common use > (comment #11) See comment #6. > Why are you ignoring these FACTS? You are ignoring other facts. Anyway, why you have so destructing attitude? You would be more useful if help in writing of patches. (I have written patches for Subversion, Coreutils and MC.) Please fix your attention on writing of patches for other packages.
(In reply to comment #110) > You would be more useful if help in writing of patches. s/help/you help/
(In reply to comment #110) > (In reply to comment #109) > > You still haven't addressed the points raised in comment #19. > > There are no valid points raised in comment #19. > > > It's been pointed out to you, that these abbreviations ARE in common use > > (comment #11) > > See comment #6. This has nothing to do with it. We're talking about abbreviated month names, not numbers. > > Why are you ignoring these FACTS? > > You are ignoring other facts. For example? > Anyway, why you have so destructing attitude? > You would be more useful if help in writing of patches. We wouldn't need any patches if the change hasn't been introduced in the first place.
(In reply to comment #112) > We wouldn't need any patches if the change hasn't been introduced in the > first place. We would have still needed them, because abbreviated months are incorrect. So again: /----------------------------------------------------------------------------\ | Everybody please list still maintained packages which may need to be fixed.| \----------------------------------------------------------------------------/
(In reply to comment #113) > So again: > /----------------------------------------------------------------------------\ > | Everybody please list still maintained packages which may need to be fixed.| > \----------------------------------------------------------------------------/ And what with new packages? How much years will you observing and guarding new packages? Now I know, you know everything about Poles, polish language and programs. So maybe you are immortal too?
No answer? Ok, so: You're no God. You will no live always and you'll never change all programs. You'll never *find* all programs for changing (You know, if there is no programs on your box than it doesn't exist - Comment #75). Once again: I opened a bug report because Roman numerals are incorrect. Three letters, without dots are correct in contemporary polish language (Comment #19) in computer systems. It is correct with ISO/IEC TR 14652 too. Revert abmon and abday to previous, normal version and open your own bug. In you're bug report prove that arabic numerals are correct and dots are necessary. Don't try to introduce and force your private opinion in bug 4789 report. Your way is to prove that Roman numerals are correct or revert earlier version of abmon and abday. Other ideas are for other bug report. Additional: I am please you, read about Sisyphus and Occam's razor than you'll understand more about computer programs.
(In reply to comment #115) > Comment #75 Later I found that SEAudit belongs to SETools, which are available in my distribution. > I opened a bug report because Roman numerals are incorrect. They are correct. > Three letters, without dots are correct in contemporary polish language They are incorrect. > Don't try to introduce and force your private opinion in bug 4789 report. It is the objective fact, not my private opinion.
(In reply to comment #116) > Later I found that SEAudit belongs to SETools, which are available in my > distribution. Congratulation. (are You fallible?) > > I opened a bug report because Roman numerals are incorrect. > > They are correct. attachment (id=1940) attachment (id=1941) Correct, but unusable and troublesome. For me it's mean incorrect. Programs are for people, not inversely. > > Three letters, without dots are correct in contemporary polish language > > They are incorrect. ??? * From comment #19 "http://poradnia.pwn.pl/lista.php?id=8124 [(Abbreviating names of days and month) Language guide of PWN] Jan Grzenia PhD Lecturer, author of this article is from University of Silesia, Faculty of Philology Institute of Polish Language Division of Contemporary Polish Language. http://english.us.edu.pl/?op=kstel_info&id_prac=645&PHPSESSID=4ec4ec29d53f3e52b7be86bc96b1b48e In short: "in computer systems, ortographical rules can be violate e.g. pon., wto., ¶ro., czw., pi±., sob., nie. (this abb. can be with no dots too), but the rules how to do it and for what, must be strictly defined". * From comment #84 (question without your answer) "you're not Polish language specialist. Jan Grzenia is. Are you really sure your skills in orthography are higher?" > > Don't try to introduce and force your private opinion in bug 4789 report. > > It is the objective fact, not my private opinion. Your private opinion - this is an objective fact.
(In reply to comment #117) > (In reply to comment #116) > > (In reply to comment #115) > > > Three letters, without dots are correct in contemporary polish language > > > > They are incorrect. > > ??? > > * From comment #19 > "http://poradnia.pwn.pl/lista.php?id=8124 [(Abbreviating names of days and > month) Language guide of PWN] > Jan Grzenia PhD Lecturer, author of this article is from University of > Silesia, Faculty of Philology Institute of Polish Language Division of > Contemporary Polish Language. > > http://english.us.edu.pl/?op=kstel_info&id_prac=645&PHPSESSID=4ec4ec29d53f3e52b7be86bc96b1b48e He was speaking about bent rules which could be used if there was no other, better possibility. But there is the other, significantly better possibility - to use arabic numerals. > > > Don't try to introduce and force your private opinion in bug 4789 report. > > > > It is the objective fact, not my private opinion. > > Your private opinion - this is an objective fact. No.
Arabic numerals will be a big pain in the ass, IMHO it's better to stick with roman one if it is desired to be 1000 % correct. Examples: - firewall module for kadu - unmaintained (but still used) software - new software which might hard-code the endianess of the date. I am about to exit this stupid flamewar.Let me summarise what I have seen here: some kind of language purist pushed the bug 3156 change, which seems to be irritating to most of the users due to being less readable. JuSt LiKe ThIs KiNd oF wRiTiNg. Looks that despite being not entirely correct, yet acceptable, the older variant was working well for most of the folks out there. What is being proposed here (the arabic numerals) is only going to lead to more mess, because nobody will *ever* be able to fix the hard-coded endianess issues in every single program. It is like fighting the windmills.
Rada Jezyka Polskiego (Council of Polish Language) http://www.rjp.pl/index.php the highest organ on language questions in Poland, on 10 jun 2005 gave answer. There are 4 equal groups of abbreviations for computer programs: a) s-ñ, l-y, m-c, k-ñ, m-j, c-c, l-c, si-ñ, w-ñ, p-k, l-d, g-ñ; b) st., lt., mrz., kw., mj., czrw., lp., sp., wrz., prn., lst., gr.; c) stñ, ly, mrz, kñ, mj, czc, lc, sñ, wñ, pk, ld, gñ; d) STY, LUT, MAR, KWI, MAJ, CZE, LIP, SIE, WRZ, PA¬ (lub PAZ), LIS, GRU. In localedata and in ISO/IEC TR 14652, point "d)" was always. Three letters and no dots. http://www.rjp.pl/?mod=kr&type=ort&subtype=37&id=123
(In reply to comment #120) > Rada Jezyka Polskiego (Council of Polish Language) http://www.rjp.pl/index.php > the highest organ on language questions in Poland, on 10 jun 2005 gave answer. > There are 4 equal groups of abbreviations for computer programs: > a) s-ñ, l-y, m-c, k-ñ, m-j, c-c, l-c, si-ñ, w-ñ, p-k, l-d, g-ñ; > b) st., lt., mrz., kw., mj., czrw., lp., sp., wrz., prn., lst., gr.; > c) stñ, ly, mrz, kñ, mj, czc, lc, sñ, wñ, pk, ld, gñ; > d) STY, LUT, MAR, KWI, MAJ, CZE, LIP, SIE, WRZ, PA¬ (lub PAZ), LIS, GRU. This wasn't any binding decision but a proposition for a person who wanted such incorrect abbreviations. There is clearly written that each such a project is in disaccordance with rules of Polish ortography. GLibC doesn't need such incorrect abbreviations. Roman numerals are still better.
(In reply to comment #118) > rules which could be used if there was no other, > better possibility. Hmm. Could you cite in polish, please. There is no sentence like your: "could be used if there was no other, better possibility". Why are you lying now?
(In reply to comment #122) > (In reply to comment #118) > > rules which could be used if there was no other, > > better possibility. > > Hmm. Could you cite in polish, please. It wasn't citation of any person, but of the objective truth. > Why are you lying now? You are misinterpreting my words.
(In reply to comment #123) > (In reply to comment #122) > > (In reply to comment #118) > > > rules which could be used if there was no other, > > > better possibility. > > > > Hmm. Could you cite in polish, please. > > It wasn't citation of any person, but of the objective truth. Your saying so doesn't make it true. You're not an expert. In cases like this you have to rely on language rules, as well as existing usage and common sense. You seem to ignore the last two. Following the rules blindly is not wise. The already cited experts agree that for this specific, special purpose we can ignore those rules, because the generic rules do not apply here. Existing, widespread usage supports this. Common sense supports this. Use of natural language in computer systems will cause problems which cannot always be resolved sensibly by adapting the system. Sometimes you have to bend the rules a bit. Do you know the KISS rule? Apply it.
Comment #6 shows that the existing usage is of "29.08.2007" format. It is also in accordance with common sense, because it is easy to understand.
(In reply to comment #121) > This wasn't any binding decision but a proposition for a person who wanted > such incorrect abbreviations. He doesn't want incorrect abbreviations. He want month abbreviations for COMPUTER PROGRAM. [Pytanie z trzeciego listu dotyczy³o skrótów nazw miesiêcy − takie rozwi±zanie techniczne by³o potrzebne p. Jaros³awowi W³odarczykowi na potrzeby przygotowywanego oprogramowania] Proposition made by Council of Polish Language is more mandatory than Arfrever's > There is clearly written that each such a > project is in disaccordance with rules of Polish ortography. Next brag. This solutions aren't in touch with GENERAL LANGUAGE (not "project is in disaccordance with rules of Polish ortography"). [Ze wzglêdu na mo¿liwo¶æ nieporozumienia nale¿y powtórzyæ, ¿e ¿adne z podanych rozwi±zañ nie odnosi siê do jêzyka ogólnego] It's mean that this abbreviations aren't for articles, poems or novels. Do You understand what you are reading?
(In reply to comment #125) > Comment #6 shows that the existing usage is of "29.08.2007" format. It is also > in accordance with common sense, because it is easy to understand. attachment (id=1945) attachment (id=1948) Comment #72 Comment #77
(In reply to comment #126) > He doesn't want incorrect abbreviations. He want month abbreviations for > COMPUTER PROGRAM. But we don't have to have such poor requirements for %b, when we could use the better alternative. > This solutions aren't in touch with GENERAL LANGUAGE (not "project is in > disaccordance with rules of Polish ortography"). > [Ze wzglêdu na mo¿liwo¶æ nieporozumienia nale¿y powtórzyæ, ¿e ¿adne z podanych > rozwi±zañ nie odnosi siê do jêzyka ogólnego] > It's mean that this abbreviations aren't for articles, poems or novels. You are confusing general language with literary language. General language concerns much more areas than you think about. > Do You understand what you are reading? Yes, in contrary to you. (In reply to comment #127) > (In reply to comment #125) > > Comment #6 shows that the existing usage is of "29.08.2007" format. It is also > > in accordance with common sense, because it is easy to understand. > > attachment (id=1945) attachment (id=1948) > Comment #72 Comment #77 These programs don't use the localized order of date parts. (The last release of ScrollKeeper was in 2003, so this program is dead, so it shouldn't be used as nobody will fix any errors, some of them possibly related to security.)
Yet, scrollkeeper is still used quite widely. Farewell don Kichote, good luck being the endianess guard. Even for the packages you don't give a damn about or have never heard of.
(In reply to comment #128) > But we don't have to have such poor requirements for %b, when we could use the > better alternative. You mean that digits, like in very old electronic hand watches are better alternative for modern computer systems? Congratulations for your taste. > You are confusing general language with literary language. General language > concerns much more areas than you think about. Have you ever read historical, biological or science articles?. Maybe you treating newspapers articles as literary? Ok. it's your mind, but don't fabricate what I am thinking about. > > Do You understand what you are reading? > > Yes, in contrary to you. So read carefully your comment #118 and my question from comment #122 > These programs don't use the localized order of date parts. Great! You understand now that you want to introduce a bug for such a programs! In comment #72 and comment #77 I was talking about consequences. > (The last release of ScrollKeeper was in 2003, so this program is dead, so it > shouldn't be used (..) Why are you talking to people what to do? What do you think who are you? ____________________________________________ To summarize: 1. Most european countries are using 3 letters abmon and abday (Comment #49) and don't talk your ill: "Anglo-centrist" or "anglophones" because I'm thinking that you are Anglophobe. 2. In Poland, in computer systems (http://poradnia.pwn.pl/lista.php?id=8124) or computer programs (http://www.rjp.pl/?mod=kr&type=ort&subtype=37&id=123) using this abbreviation are fully permitted an accepted by Council of Polish Language, expert from Faculty of Philology Institute of Polish Language Division of Contemporary Polish Language. It is accepted by normal people too (read this bug report carefully) 3. Day and month abbreviations are in accordance to ISO/IEC TR 14652 4. These abbreviations was used from years so it is "best practice" === 5. Three letters abmon and abday solving a lot of problems with unmaintainted but widely used programs. 6. Three letters abmon and abday solving problems with programs which don't use the localized order of date parts 7. Three letters abmon and abday will solving a date problem in new or broken programs. All this arguments are well documented in bug 4789 report Now it is the time for your arguments. Pure, clear arguments.
(In reply to comment #130) > using this abbreviation are fully permitted an accepted by Council of Polish > Language, expert from Faculty of Philology Institute of Polish Language > Division of Contemporary Polish Language. It is accepted by normal people too Acception by normal people should be the main argument to restore all things as they were before. Because a normal person (like me) created patchs to make abbreviations more readable. Normal person created a topic on forum.fedora.pl (http://forum.fedora.pl/ index.php?showtopic=15048) thinking that his mistake caused wrong date-format. Normal people was shouting on #fedora-pl irc-channel that they want old date- format. Normal person named "pt., 27.07.2007, 22:39:40 CEST" a monster on gentoo forum: http://forums.gentoo.org/viewtopic-p-4166255-highlight-.html#4166255 That's why we have to return to the original state. Because normal people want it.
No arguments Mr. Arfrever Frehtes Taifersar Arahesis? OK, I understand, but Linux community are stronger than Your recusance. http://arcon.svn.sourceforge.net/viewvc/arcon/trunk/overlay/sys-libs/glibc/files/2.6/ I'm thinking you're very good material for Bill G. - nothing for people and no standards.
(In reply to comment #132) > No arguments Mr. Arfrever Frehtes Taifersar Arahesis? I had already posted many valid and sufficient arguments. Currently I'm busy with improving other software than convincing unconvinceable people like thou.
(In reply to comment #133) > I had already posted many valid and sufficient arguments. So had we. > Currently I'm busy with improving other software than convincing > unconvinceable people like thou. The only unconvinceable person here is you. I can image a situation where all the people (Polish users obviously) change their date format but it's not provided by glibc because one man decided to make it his own way.
(In reply to comment #134) > one man decided to make it his own way. I'm not the only one person who likes 18.09.2007 format. This bug isn't very well known.
(In reply to comment #135) > I'm not the only one person who likes 18.09.2007 format. Words, words, words. Examples please.
(In reply to comment #135) > > > one man decided to make it his own way. > > This bug isn't very well known. There are searching tools like google for example. Try it. * Fedora 7: http://ecik.nonlogic.org/blog/wpisy/31-daty-w-f7 * Gentoo: http://arcon.svn.sourceforge.net/viewvc/arcon/trunk/overlay/sys-libs/glibc/files/2.6/ * Archlinux: http://bugs.archlinux.org/task/7444 * Ubuntu: https://bugs.launchpad.net/ubuntu/+source/langpack-locales/+bug/133667 Need more?
Created attachment 2012 [details] Unicode CLDR 1.5 Unicode Common Locale Data Repository, Version 1.5 No digits for month abbreviations, but three letters. * for all documents: http://unicode.org/Public/cldr/1.5.0/ This is very good example for your understanding stupid discussion about general language or literary language (comment #128) For what so much ignorance?
What is CLDR? http://www.unicode.org/cldr/
(In reply to comment #136) > (In reply to comment #135) > > > I'm not the only one person who likes 18.09.2007 format. > > Words, words, words. > Examples please. Comment #6.
(In reply to comment #140) > > I'm not the only one person who likes 18.09.2007 format. > > Words, words, words. > > Examples please. > > Comment #6. Do you really think they "likes" this format or only using incorrect abmon? * Comment #11 * ISO/IEC TR 14652 * Common Locale Data Repository, Version 1.5 and next distributions: * Debian: http://permalink.gmane.org/gmane.linux.debian.devel.bugs.general/279616 * Suse https://bugzilla.novell.com/show_bug.cgi?id=302371 or sourceware.org bug 4098
Why are you trying with polish locales? Begin your world reparing with en_US. Why they have 3 letters month abbreviation in glibc locale. Repair it and do correct. Here are examples (they likes digits too): http://www.usa.gov/ http://www.archives.gov/press/ http://hubble.nasa.gov/ Or fr_FR: http://www.elysee.fr/ http://www.premier-ministre.gouv.fr/fr/ http://www.senat.fr/ http://www.mediateur-republique.fr/ And give peace to polish locales. Make it according to standards, not lazy web designers. (by the way do you know what IIS is?)
(In reply to comment #3) > You need to dispute > Usually claims that something in locale is incorrect are highly subjective, > you need to prove it with standard reference, or if there is a lack thereof, > with newspaper references, etc. The longer dispute make no sense. So references: * ISO/IEC TR 14652 three first letters as month abbreviation for polish locales. No roman numerals. No arabic digits. * CLDR, version 1.5 three first letters as month abbreviation for polish locales, example for January: <month type="1">sty</month> <month type="1" alt="proposed-x1001" draft="unconfirmed">st</month> <month type="1" alt="proposed-x1002" draft="unconfirmed">I</month> Roman numerals and other abbreviation "st" marked as: "proposed", "unconfirmed". No arabic digits Common Locale Data Repository are used by programs, authors and maintainers today. GNU Classpath for example: "The locale data for GNU Classpath is currently being auto-generated using the data provided by the CLDR project. CLDR provides locale data in XML files using LDML version 1.2. The tools gnu.localegen and gnu.currencygen written by Guilhelm Lavaux convert that data into a format suitable for GNU Classpath (These tools are located in the CVS module "cp-tools".)" or * http://developer.classpath.org/doc/java/util/Calendar-source.html You must make decision please, what to do next. Be compatible with software build against CLD Repository (in CLDR abmon is in accordance to ISO/IEC TR 14652), or introduce new, nonexistent in programs version of polish abbreviated month name. The Unicode org CLDR are open, so young maintainer can convincing people at: * http://www.unicode.org/cldr/data/docs/web/survey_tool.html And one question: * What is Keld opinion about CLDR? Best regards.
Subject: Re: incorrect abmon in polish locales On Fri, Sep 21, 2007 at 09:54:15AM -0000, r_runner at poczta dot onet dot pl wrote: > > And one question: > * What is Keld opinion about CLDR? I am not so happy about CLDR. It seems to be yet another attempt from Unicode to take over the world of internationalization. They could have chosen to cooperate internationally with the ISO guys and the glibc people, but they chose to make their own database. I will, however investigate how cooperation could be made. Best regards keld
(In reply to comment #144) > Best regards > keld Thank you very much for your response. Best regards RR
Created attachment 2020 [details] Open Source Linux Locale Data in XML In this paper, in Conclusion, is very wise sentence: "Locale data is not different among platforms or vendors because it depends only on the language and the country" So independently of other problems CLD Repository version 1.5 are very fresh (2007-07-31) and Polish abmon is represented by three letters abbreviation as it is in ISO/IEC TR 14652 Best regards
Any news on this issue? When can we expect fixed Polish locale? Which glibc version will have fixed Polish locale? Now I use glibc 2.5 locales on glibc 2.6 because of this bug.
I made alternative pl_PL file. Just copy it to /usr/share/i18n/locales/ and do localedef -ci pl_PL -f ISO-8859-2 pl_PL It still uses Roman month number but in formatted way. Just use 'ls -l' to view it. Another new feature is to cover Roman numbers in data formats. date: czw, 27 IX 2007, 03:59:48 CEST date +%x: 27-09-2007 date +%c: czw, 27 IX 2007, 04:01:26 new abday: ndz pon wt śr czw pt sob
Created attachment 2022 [details] alternative pl_PL locale Roman month number formatting attempt I first was against Roman month numbering. Then I realized sometimes see American date format where month and day position is reversed. E.g. try to correctly understand 04-07-2007 date. In USA it will be 7th April 2007 In Europe this will be 4th July 2007 Using Roman months can help recognize which format is used. Formatted Roman month display should fix output garbage. I also made fix for mc. Will post it if this idea will catch up. date +%x will provide official date format: 27-09-2007
(In reply to comment #149) > Using Roman months can help recognize which format is used. Using the old format (sty, lut, mar...) always helped recognize which format is used.
I will soon provide new pl_PL locale with removed Roman month numbering. I'm voting for using ISO 8601 standard for Polish locale. I think also making posix default locale to use ISO 8601 instead of U.S. date/time format would be the good thing(tm). ISO 8601 standard is widely accepted and will make Linux settings more international by default.
(In reply to comment #151) > I'm voting for using ISO 8601 standard for Polish locale. +1 > I think also making posix default locale to use ISO 8601 instead of U.S. > date/time format would be the good thing(tm). +1 > ISO 8601 standard is widely accepted and will make Linux settings more > international by default. +1 (In reply to comment #149) > I also made fix for mc. MC trunk has been already fixed in some way. Subversion trunk is also fixed.
(In reply to comment #151) > I will soon provide new pl_PL locale with removed Roman month numbering. > I'm voting for using ISO 8601 standard for Polish locale. I think also > making posix > default locale to use ISO 8601 instead of U.S. date/time format would be the > good thing(tm). ISO 8601 standard is widely accepted and will make Linux > settings more international by default. You've got it: #date --iso-8601 This is no voting club, but questions what to use for: #date +%b in polish locales. As it is in standards or introducing new private quasi-standard with digits. Best regards
We've created a poll to finally determine which format to use. Please vote here: http://karlik.nonlogic.org/blog/wpisy/ogolne/daty-w-glibc-sonda Vox populi vox Dei.
You should remove the ISO format from the poll. It makes no sense. You can always use it explicitly if you want. THe format in question is about the traditional format and has nothing whatsoever to do with the ISO 8601 spec.
And, even if your locale's date_fmt, d_fmt and d_t_fmt don't include %b, but writes month using %m, it would be good to vote how should the month abbreviations look like, for people who will use %b in strftime, date +FMT, etc.
The poll has been changed after above comments.
The current cvs contains changes according to the results of the poll
I'm sorry for long time with no answering but net isn't everywhere. Yes. This bug was open because of "incorrect abmon in polish locales". Now abmon is correct. So, for me there is no more bug and my proposition is to close it like another instance of this problem: https://bugzilla.redhat.com/show_bug.cgi?id=242296 ------------- ---------------- Thanks to all for participation. Best regards RR
*** Bug 260998 has been marked as a duplicate of this bug. *** Seen from the domain http://volichat.com Page where seen: http://volichat.com/adult-chat-rooms Marked for reference. Resolved as fixed @bugzilla.