This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Comment 10 in #29555 seems as if it could just as well apply to years that then are formatted Roman numbers. Printing 2007 with '[Yi,3-3]' as vii instead as mmvii like in test case format-dateTime-006
So how would you use that rule to format the year 1999? I don't think years in roman numerals have ever been expressed modulo 100, and if they had, you couldn't express the requirement to do so by means of a minimum or maximum width.
999 ? cmxcix Makes as much sense as truncating year 654321 to 54321 with max width 5
The point of the truncation logic is to get the year to fit within the maximum width. format-date(xs:date("1998-01-01"), "[Y,2-2]") => 98 format-date(xs:date("1999-01-01"), "[Y,2-2]") => 99 If we applied this logic in the case of roman numerals, it would fail to print a value within the maximum width in many cases. format-date(xs:date("1998-01-01"), "[Yi,2-2]") => xcviii (instead of mcmxcviii) format-date(xs:date("1999-01-01"), "[Yi,2-2]") => xcix (instead of mcmxcix) And in some cases it will unnecessarily truncate the value. format-date(xs:date("0101-01-01"), "[Yi,2-2]") => i (instead of ci)
On the whole people working with Roman numerals and fixed-width fields are in for a hard time, and will probably use string processing to do what they need. It seems specialist enough that I've no clue how to predict a "majority" use case. Josh's result - apply the width in decimal before conversion - and Benito's - apply the width in characters after conversion - both seem plausible and I don't see any reason to prefer one over the other in general. Benito, when you opened this bug you didn't say that anything was wrong, nor what goes wrong, nor what you think ought to happen. Is anything wrong with the spec here?
I implemented comment 10 of #29555 and afterwards that test case failed The comment says to truncate the year if there is a max width without exception The specs says somewhere >If no mechanism is available for fitting the value within the specified maximum width (for example, when roman numerals are used), then the value should be output in its full representation. but the comment provides a mechanism for the year and it gets shorter, even if it stays too long.
>Josh's result - apply the width in decimal before conversion - and Benito's - apply the width in characters after conversion - both seem plausible You switched me and Josh
Please note that we currently say the following already about roman numerals and the width modifier: "If no mechanism is available for fitting the value within the specified maximum width (for example, when roman numerals are used), then the value should be output in its full representation."
(which typically means that implementations are allowed to do as they wish if they feel that there is such mechanism, making it implementation-defined what happens if you try to truncate roman numerals, but the suggestion of the text, by means of "should", is to do nothing in such cases)
At the meeting on 2016-06-14, the WG discussed this and acknowledge the comment. This will be used as input to the existing action item A-643-01 (MikeK to update proposal on Bug 29555)