Bug 15403 - en_CA: locale should use 4-digit year
Summary: en_CA: locale should use 4-digit year
Status: RESOLVED DUPLICATE of bug 9842
Alias: None
Product: glibc
Classification: Unclassified
Component: localedata (show other bugs)
Version: 2.17
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-04-25 21:42 UTC by Ryan Armstrong
Modified: 2016-08-10 10:06 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-

Attachments
en_CA patch (292 bytes, patch)
2013-04-26 20:53 UTC, Ryan Armstrong 		Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Ryan Armstrong 2013-04-25 21:42:06 UTC 
The current date-time format for en_CA uses the 2-digit year (%y) for the short date format. After the year 2000, it has become customary to use a 4-digit date to avoid confusion. The en_US locale has already been updated to use a 4-digit date, but the en_CA locale is unfortunately left behind.
Comment 1 Carlos O'Donell 2013-04-25 23:10:13 UTC 
Ryan,

Thanks for submitting this.

Care to make a patch to fix this?
Comment 2 Ryan Armstrong 2013-04-26 20:53:35 UTC 
Created attachment 7003 [details]
en_CA patch

Easily done. Note that I forgot I had Geany set to automatically convert tabs to spaces, which resulted in one more change in the patch. Since the entire rest of the file uses spaces to begin with, I figured that was also a worthwhile change and left it in.
Comment 3 Mike Frysinger 2015-08-29 20:31:05 UTC 

*** This bug has been marked as a duplicate of bug 9842 ***
Comment 4 Ryan Armstrong 2015-09-05 17:27:29 UTC 
I would appreciate if this bug wasn't treated as exactly the same as bug 9842. Bug 9842 is about the difference between d/m/y and y-m-d.

This bug is simply about getting a 4-digit year on the en_CA locale, which I think we can all agree on. I tested my patch, and it's still valid. So long as someone can accept the patch, the bug can be closed and bug 9842 can remain open for the corresponding (probably lengthy) debate.
Comment 5 Mike Frysinger 2016-08-10 10:06:07 UTC 
still largely the same issue and is fixed once that bug is resolved

*** This bug has been marked as a duplicate of bug 9842 ***