Closed Bug 483769 Opened 13 years ago Closed 13 years ago

dateFormatYearMonth should generate 4 digits year

Categories

(Core :: Internationalization, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla1.9.2a1

People

(Reporter: dev-null, Assigned: dev-null)

References

Details

(Keywords: verified1.9.1, Whiteboard: [fixed on 1.9.1 by bug 360018])

Attachments

(1 file)

Spun off from Bug 360018 Comment #54.

On Windows, dateFormatYearMonth's result is yyyy/MM.
On Linux and Mac, dateFormatYearMonth's result is yy/MM.
These should be consistent.

Besides yy/MM is not good because it has y2k problem, and also it is misleading for some locales against MM/yy.
So the result should be yyyy/MM on all platforms.
Attachment #367757 - Flags: review?(smontagu)
Attachment #367757 - Flags: review?(smontagu) → review+
Keywords: checkin-needed
Blocks: 360018
Comment on attachment 367757 [details] [diff] [review]
Patch v1.0
[Checkin: Comment 1]


http://hg.mozilla.org/mozilla-central/rev/38bf155ba088
Attachment #367757 - Attachment description: Patch v1.0 → Patch v1.0 [Checkin: Comment 1]
Status: NEW → RESOLVED
Closed: 13 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.2a1
This was a trunk only issue and never needed for 1.9.1?
Keywords: fixed1.9.1
Whiteboard: [fixed on 1.9.1 by bug 360018]
Verified on trunk and 1.9.1 with builds on OS X / Linux and the following snippet:

window.alert(Components.classes["@mozilla.org/intl/scriptabledateformat;1"].createInstance(Components.interfaces.nsIScriptableDateFormat).FormatDate("de",3,2000,12,31));

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090422 Minefield/3.6a1pre ID:20090422030859

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090422 Shiretoko/3.5b4pre ID:20090422032535

A test would be nice, if we don't have one yet.
Status: RESOLVED → VERIFIED
Flags: in-testsuite?
You need to log in before you can comment on or make changes to this bug.