This is the mail archive of the
libc-locales@sourceware.org
mailing list for the GNU libc locales project.
[Bug localedata/12731] en_CA: date-time format doesn't respect CAN/CSA-Z234.4 - ISO 8601
- From: "carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: libc-locales at sourceware dot org
- Date: Fri, 20 May 2016 13:52:36 +0000
- Subject: [Bug localedata/12731] en_CA: date-time format doesn't respect CAN/CSA-Z234.4 - ISO 8601
- Auto-submitted: auto-generated
- References: <bug-12731-716 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=12731
Carlos O'Donell <carlos at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |carlos at redhat dot com
--- Comment #7 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Alexandre Demers from comment #2)
> According to National Research Council Canada (NRC) and to Standard Council
> of Canada (SCC), the standard for date time format in Canada has to follow
> CAN/CSA-Z234.4 which says mostly the same as ISO 8601. Have a look at the
> official site
> (http://www.nrc-cnrc.gc.ca/eng/ibp/inms/about/faq-time.html#Q8):
>
> "Canadian Standard CAN Z234-4 specifies numeric representations of date and
> time. The recommended full format is of the form 2001-12-31 23:59:28.73 UTC.
> It is compatible with International Standard ISO 8601."
>
> This means this is the format people are (should be) expecting. Thus, the
> current locale file is incorrect and the patch should be applied. Without
> the patch, the en_CA locale follows the US standard, which is one of the
> none official way of writting the date time format here (we use three
> different ways to write date time, but only one is official and should be
> used).
As a participating member of SCC's CAC/JTC1/SC22 my perspective is that while
the standard is fine for Government use, the en_CA locale is intended for
colloquial use. If you have government uses then you need to create your own
locale.
I believe we will solve this with a C.UTF-8@ISO8601 locale that follows the ISO
8601 time standard and can be used for LC_TIME to replace the current locales
time.
--
You are receiving this mail because:
You are the assignee for the bug.