This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Over ten years ago, as a result of bug #3018, the following sentence was added to the spec: In the case of the fractional seconds component, the value is rounded to the specified size as if by applying the function round-half-to-even(fractional-seconds, max-width). and it seems this has gone unchallenged since. So what exactly is the output of format-time(xs:time("12:01:01.9999", "[s99].[f99]")) In particular, how does one round a fractional seconds value such as .9999 to a maximum width of two digits by following the round-half-to-even rule?
It's hard to come up with a fully satisfactory solution to this. I think we should rule out all solutions that attempt to round 01.9999 "properly" to 02.0000, changing the seconds value, because it would be very disruptive for the formatting of one component to affect the output of another. I think there are two possible choices: (A) Abandon rounding and switch to truncation. Truncation always works and is consistent with the general approach of the function: if the value is 12:59:59 and you choose not to output the seconds, the output is 12:59, not 13:00. It's an incompatible change, but it's a change to something that can never have worked properly. (B) Specify that if rounding the fractional seconds would cause the seconds value to change, we truncate instead. So 1.9999 "rounds" to 1.99. I think my preference is to take the compatibility hit and go for (A).
>So what exactly is the output of >format-time(xs:time("12:01:01.9999", "[s99].[f99]")) For Saxon, in recent releases at any rate, the output has been "01.00". Not nice.
The WG decided on option (A) in comment (1): switch to truncating rather than rounding.
The spec and test cases have been updated.
Wouldn’t it make sense to also apply the rule to fn:dateTime? If yes, I guess that the following testcases should be revised: * format-dateTime-002g * format-dateTime-002h * format-dateTime-002i * format-dateTime-003m * format-dateTime-003n * format-dateTime-003p * format-dateTime-013s * format-dateTime-013u
Yes the new rule obviously applies to fn:format-dateTime() as well, and there may well be other test cases that need updating.
I have taken the liberty of correcting the expected results for these tests.
Based on Tim's comment #7, I have marked this bug as resolved/fixed. Please reopen if you believe any more work needs to be done. Thanks.