This is an ongoing problem whose resolution seems stymied by an intransigent maintainer. See bug: Bug 12731 and Bug 9842. The Government of Canada requires that dates and times on official documents be formatted according to the ISO8901. If altering the locales en_CA and fr_CA are out of the question then cannot two supplemental locales, say en_CA@ISO and en_fr@ISO, that address this issue be provided as well? We deal with the Canadian Government via EDI and they require yyyy-mm-dd on our transmissions. We have had the painful experience of having to create our own LOCALE definition file and then distribute it in order that our RedHatEL6 based systems reflect this requirement. We filed a bug with RH and they directed us here. Based on what I have read about this issue elsewhere on this site I have little confidence that anything constructive will be done. I must say that I was nonplussed when I read this statement in bug: 12731: > It is completely irrelevant what should be expected. Locales are > about what people are using. Programs displaying times all should > have a special ISO 8601 mode and that's how you allow people to > read the time this way. If you don't like that then compile your > own locale. That's why there is a standardized lcoaledef program. > But I'm not going to change the format everyone but you expect under > people's feet." In point of fact, my experience with LOCALEs on Linux is that the one most often used in Canada is en_US whose date format conforms neither with what 'everyone' in Canada is supposedly using according to the above statement nor with what the Canadian Government has mandated. Anyone who is selecting to use either the en_CA or fr_CA is already in a tiny minority. Given the mindset evidenced in the argument used above to not include ISO8601 date time formats in them one can only wonder then why en_CA and fr_CA local definitions are provided at all. Further, programs such as OpenOffice and LibreOffice depend upon the LOCALE setting for their default formats and have maintainers that are as steadfast in their refusal to provide an easy means for users to set a different default as the glibc maintainers are in changing the en_CA or fr_CA locales to meet the legal standard. I have used the recommended, if woefully under-documented and Byzantinely arcane, so-called standardized localedef program, whose syntax and usage are a mute, and I mean MUTE -- why is there no man page for this? --, testament to why *nix OSes are so unnecessarily hard to deal with. Making end users responsible for customizing their LOCALEs with an obscured<sic> cli utility program because they are not just like 'everyone' else seems a little callous. Or perhaps painfully encoding the necessary strftime formatting characters into UTF-8 code-points is something that every user of glibc should just get comfortable with. Is this what you really expect an end user to have to deal with just to set the default date format on their systems? LC_TIME abday "<U0053><U0075><U006E>";"<U004D><U006F><U006E>";/ "<U0054><U0075><U0065>";"<U0057><U0065><U0064>";/ "<U0054><U0068><U0075>";"<U0046><U0072><U0069>";/ "<U0053><U0061><U0074>" day "<U0053><U0075><U006E><U0064><U0061><U0079>";/ "<U004D><U006F><U006E><U0064><U0061><U0079>";/ "<U0054><U0075><U0065><U0073><U0064><U0061><U0079>";/ "<U0057><U0065><U0064><U006E><U0065><U0073><U0064><U0061><U0079>";/ "<U0054><U0068><U0075><U0072><U0073><U0064><U0061><U0079>";/ "<U0046><U0072><U0069><U0064><U0061><U0079>";/ "<U0053><U0061><U0074><U0075><U0072><U0064><U0061><U0079>" abmon "<U004A><U0061><U006E>";"<U0046><U0065><U0062>";/ "<U004D><U0061><U0072>";"<U0041><U0070><U0072>";/ "<U004D><U0061><U0079>";"<U004A><U0075><U006E>";/ "<U004A><U0075><U006C>";"<U0041><U0075><U0067>";/ "<U0053><U0065><U0070>";"<U004F><U0063><U0074>";/ "<U004E><U006F><U0076>";"<U0044><U0065><U0063>" mon "<U004A><U0061><U006E><U0075><U0061><U0072><U0079>";/ "<U0046><U0065><U0062><U0072><U0075><U0061><U0072><U0079>";/ "<U004D><U0061><U0072><U0063><U0068>";/ "<U0041><U0070><U0072><U0069><U006C>";/ "<U004D><U0061><U0079>";/ "<U004A><U0075><U006E><U0065>";/ "<U004A><U0075><U006C><U0079>";/ "<U0041><U0075><U0067><U0075><U0073><U0074>";/ "<U0053><U0065><U0070><U0074><U0065><U006D><U0062><U0065><U0072>";/ "<U004F><U0063><U0074><U006F><U0062><U0065><U0072>";/ "<U004E><U006F><U0076><U0065><U006D><U0062><U0065><U0072>";/ "<U0044><U0065><U0063><U0065><U006D><U0062><U0065><U0072>" d_t_fmt "<U0025><U0061><U0020><U0025><U0064><U0020><U0025><U0062><U0020><U0025><U0059><U0020><U0025><U0072><U0020><U0025><U005A>" % Original date format (%m/%d/%Y) %d_fmt "<U0025><U0064><U002F><U0025><U006D><U002F><U0025><U0079>" % Custom date format (%Y-%b-%d) d_fmt "<U0025><U0059><U002d><U0025><U0062><U002d><U0025><U0064>" % Original time format %r (%H:%M:%S am|pm) %t_fmt "<U0025><U0072>" %am_pm "<U0041><U004D>";"<U0050><U004D>" %t_fmt_ampm "<U0025><U0049><U003A><U0025><U004D><U003A><U0025><U0053><U0020><U0025><U0070>" % 24 hour time %T (HH:mm:ss) no am/pm. t_fmt "<U0025><U0054>" am_pm "";"" t_fmt_ampm "" date_fmt "<U0025><U0061><U0020><U0025><U0062><U0020><U0025><U0065>/ <U0020><U0025><U0048><U003A><U0025><U004D><U003A><U0025><U0053><U0020>/ <U0025><U005A><U0020><U0025><U0059>" END LC_TIME And of course, all this encoding and editing is necessary before one even begins to use the localedef program, assuming one can discover its existence and uncover which files to edit. Is their any reason why supplemental en_CA@ISO and fr_CA@ISO localdefs should not be provided with glibc as an alternative for those of us 'no-ones' that have a requirement to use ISO format dates and times and are not conversant with hand encoding data into UTF-8?
$ date --iso-8601 2014-03-06
(In reply to Andreas Schwab from comment #1) > $ date --iso-8601 > 2014-03-06 And?... how is this going to make this format detected in software that looks at LANG to get its formatting information? Is that not the POINT of locales? To avoid having to set a custom default is each and every program that needs a format?
I would not use that for my own purpose, even if my government required it.
(In reply to James B. Byrne from comment #0) > This is an ongoing problem whose resolution seems stymied by an intransigent > maintainer. See bug: Bug 12731 and Bug 9842. As a Canadian my opinion is that Ulrich is wrong. Most Canadians expect that the date today should be written as 2014-02-06, and not anything else that is used by American geographies. > % Original date format (%m/%d/%Y) > %d_fmt "<U0025><U0064><U002F><U0025><U006D><U002F><U0025><U0079>" > > % Custom date format (%Y-%b-%d) > d_fmt "<U0025><U0059><U002d><U0025><U0062><U002d><U0025><U0064>" Thus this change is going to be OK and I will make this change immediately after gathering consensus from the distribution maintainers on the development list. > % Original time format %r (%H:%M:%S am|pm) > %t_fmt "<U0025><U0072>" > %am_pm "<U0041><U004D>";"<U0050><U004D>" > %t_fmt_ampm > "<U0025><U0049><U003A><U0025><U004D><U003A><U0025><U0053><U0020><U0025><U0070 > >" > > % 24 hour time %T (HH:mm:ss) no am/pm. > t_fmt "<U0025><U0054>" > am_pm "";"" > t_fmt_ampm "" This change is not OK. The average Canadian still expects 12 hour clocks with am and pm. Therefore this change should not be made. > Is their any reason why supplemental en_CA@ISO and fr_CA@ISO localdefs > should not be provided with glibc as an alternative for those of us > 'no-ones' that have a requirement to use ISO format dates and times and are > not conversant with hand encoding data into UTF-8? That is an excellent recommendation. Would you accept an en_CA@ISO locale for official compliance with ISO8901? That would not require any consensus from the distribution maintainers except to ask that they acknowledge their support for the new locale. Comments?
(In reply to Andreas Schwab from comment #3) > I would not use that for my own purpose, even if my government required it. You are free to do what you wish with your own systems. Including creating your own locales. That doesn't help the bug reporter resolver their problem. Do you have any constructive feedback on this issue?
(In reply to Carlos O'Donell from comment #4) > (In reply to James B. Byrne from comment #0) > > This is an ongoing problem whose resolution seems stymied by an intransigent > > maintainer. See bug: Bug 12731 and Bug 9842. > > As a Canadian my opinion is that Ulrich is wrong. Most Canadians expect that > the date today should be written as 2014-02-06, and not anything else that > is used by American geographies. > > > % Original date format (%m/%d/%Y) > > %d_fmt "<U0025><U0064><U002F><U0025><U006D><U002F><U0025><U0079>" > > > > % Custom date format (%Y-%b-%d) > > d_fmt "<U0025><U0059><U002d><U0025><U0062><U002d><U0025><U0064>" > > Thus this change is going to be OK and I will make this change immediately > after gathering consensus from the distribution maintainers on the > development list. > > > % Original time format %r (%H:%M:%S am|pm) > > %t_fmt "<U0025><U0072>" > > %am_pm "<U0041><U004D>";"<U0050><U004D>" > > %t_fmt_ampm > > "<U0025><U0049><U003A><U0025><U004D><U003A><U0025><U0053><U0020><U0025><U0070 > > >" > > > > % 24 hour time %T (HH:mm:ss) no am/pm. > > t_fmt "<U0025><U0054>" > > am_pm "";"" > > t_fmt_ampm "" > > This change is not OK. The average Canadian still expects 12 hour clocks > with am and pm. Therefore this change should not be made. > > > Is their any reason why supplemental en_CA@ISO and fr_CA@ISO localdefs > > should not be provided with glibc as an alternative for those of us > > 'no-ones' that have a requirement to use ISO format dates and times and are > > not conversant with hand encoding data into UTF-8? > > That is an excellent recommendation. > > Would you accept an en_CA@ISO locale for official compliance with ISO8901? > > That would not require any consensus from the distribution maintainers > except to ask that they acknowledge their support for the new locale. > > Comments? Two additional xx_CA@ISO locales that implemented strict ISO8601 would be my preferred option. I completely support NOT changing the established default behaviour of anything that causes inexplicable changes visible to end-users.
That was as constructive as it can get. The government has no influence on daily life in most parts of your personal life, outside of busines. Eg. everyone is still using horse powers, even though every car dealer is required to use units of kW.
(In reply to Carlos O'Donell from comment #4) > As a Canadian my opinion is that Ulrich is wrong. Most Canadians expect that > the date today should be written as 2014-02-06, and not anything else that > is used by American geographies. > > > % Original date format (%m/%d/%Y) > > %d_fmt "<U0025><U0064><U002F><U0025><U006D><U002F><U0025><U0079>" > > > > % Custom date format (%Y-%b-%d) > > d_fmt "<U0025><U0059><U002d><U0025><U0062><U002d><U0025><U0064>" > > Thus this change is going to be OK and I will make this change immediately > after gathering consensus from the distribution maintainers on the > development list. I think that you want %Y-%m-%d to be ISO compliant. d_fmt "<U0025><U0059><U002D><U0025><U006D><U002D><U0025><U0064>" I used the three letter short form month (%b) in the example. Had one been available then I would have simply used a straight ISO8601 localedef. But as I had to hand code it anyway I prefer to read the month directly on my desktop displays and not have to map numbers to the names of the month in my head. The servers got the the strict version.
The ISO short date format (%Y-%m-%d) is widely used in Canada. It is on bank cheques, passports, driver licenses, and MS Windows. It is specified by the Canadian Standards Association. The existing d_fmt is ambiguous, confusing, and subject to misinterpretation. It is also different from the French Canadian locale. I do not think that the ISO date code is uncomfortable for anyone in Canada. fr_CA uses the ISO code: d_fmt "<U0025><U0059><U002D><U0025><U006D><U002D><U0025><U0064>" Please make d_fmt ISO-compliant, same as fr_CA. The time codes are a different matter, common usage is different than the ISO spec.
If there are going to be xx_CA@ISO locales created then please make them strictly ISO8601 compliant. If additional locales are desired to account for the use of twelve hour o'clock style times with a.m. and p.m. suffixes then please make these available as additional derivative locales. Our need is is for strict ISO 8601 compliance. Changing the date alone does not solve the underlying problem.
afaict, since bug 9842 has landed (using %Y-%m-%d), this is now a moot request
The patch referred to in #9842 only changes the date representation. The twenty-four hour clock is not handled. So, a need for a fully ISO8901 compliant en_CA@ISO remains.