by Michael S. Kaplan, published on 2007/07/01 02:59 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/06/30/3637646.aspx
John Caffrey, one of the awesome SDETs we have over at the EDC (European Development Center) over in Dublin, sent mail the other day reporting a bug in the CultureAndRegionInfoBuilder class:
Hi guys,
We’ve noticed that the CalendarWeekRule setting being saved out to LDML by the CARIB is incorrect. i.e. here’s some code which repros the issue :-
CultureAndRegionInfoBuilder carib = new CultureAndRegionInfoBuilder("en-IE", CultureAndRegionModifiers.Replacement);
carib.GregorianDateTimeFormat.CalendarWeekRule = CalendarWeekRule.FirstFourDayWeek;
carib.Save("Test FirstFourDayWeek.ldml");
// Bug: Saved LDML file contains <msLocale:weekRule type="firstFullWeek" />
carib.GregorianDateTimeFormat.CalendarWeekRule = CalendarWeekRule.FirstFullWeek;
carib.Save("Test FirstFullWeek.ldml");
// Bug: Saved LDML file contains <msLocale:weekRule type="firstFourDayWeek" />
Just wondering if this is a known issue?
Well, it wasn't as known issue, though it certainly is now that it has been reported!
As it turns out, this is only bug in the LDML creation code, not in the code of the piece of CultureAndRegionInfoBuilder that creates custom cultures. Though it appears to be "properly" misinterpreted in both read and write operations (i.e. in both CultureAndRegionInfoBuilder.Save and CultureAndRegionInfoBuilder.CreateFromLdml), which is the most likely reason that no one noticed. :-)
It does lead to an interesting question as to whether it should be fixed or not -- since fixing it would break all prior versions of CultureAndRegionInfoBuilder for this member as well as making LDML files written by prior versions not work as well in versions that are fixed.
Maybe the answer now is to leave it alone, perhaps adding a comment to the XML to explain the "mistake" in the file so no one fixes it? :-)
A good catch, though -- this could be really confusing for people looking at the LDML directly. Kudos to the EDC, as usual!
This post brought to you by § (U+00a7, a.k.a. SECTION SIGN)
Bikedude on 1 Jul 2007 7:28 AM:
IMO: Fixing this issue could easily just as well fix many systems that are currently not aware of the bug at all (or they're perhaps waiting to use this function in anticipation of a fix).
I seldom buy into the "this fix can damage existing implementations" philosophy. This only encourages people not to report bugs, because presumably those existing systems would have had to detect the bug in the first place, in order to work around it?
--
Rune
Cristian Secară on 1 Jul 2007 7:41 AM:
The "fixing it would break all prior versions of [something]" remembers me of the ISO/IEC 8859-2 (Latin 2) "revision" (in 1998), which in fact revised nothing, thus pushing further a language problem that puzzles things over years and gave headaches to others (like Microsoft :) ...
Cristi