This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This test has the following expression: string-join( for $z in -28 to +28 return format-time(adjust-time-to-timezone($t, $z*xs:dayTimeDuration('PT30M')), '[h01][m01][z,2-6]'), '; ') The width modifier of the timezone is "2-6". The specification uses "should" in regards to using the width modifier. It also says: "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." The expected outcome here starts with: "0715GMT-14:00; 0745GMT-13:30; 0815GMT-13:00; 0845GMT-12:30" But "GMT-14:00" has width 9 and there is a valid representation with width 6. Therefore, I believe that the correct output should be: "0715GMT-14; 0745GMT-13:30; 0815GMT-13; 0845GMT-12:30" The halves are not truncated, because it would make the presentation of that timezone incorrect, so the phrase "should be output in its full representation" is applied. Since the spec uses the words "should", I think the shortened timezones are not a requirement, but they should be the preferred outcome. The complete expected string value should then be: "0715GMT-14; 0745GMT-13:30; 0815GMT-13; 0845GMT-12:30; 0915GMT-12; 0945GMT-11:30; 1015GMT-11; 1045GMT-10:30; 1115GMT-10; 1145GMT-09:30; 1215GMT-09; 1245GMT-08:30; 0115GMT-08; 0145GMT-07:30; 0215GMT-07; 0245GMT-06:30; 0315GMT-06; 0345GMT-05:30; 0415GMT-05; 0445GMT-04:30; 0515GMT-04; 0545GMT-03:30; 0615GMT-03; 0645GMT-02:30; 0715GMT-02; 0745GMT-01:30; 0815GMT-01; 0845GMT-00:30; 0915GMT+00; 0945GMT+00:30; 1015GMT+01; 1045GMT+01:30; 1115GMT+02; 1145GMT+02:30; 1215GMT+03; 1245GMT+03:30; 0115GMT+04; 0145GMT+04:30; 0215GMT+05; 0245GMT+05:30; 0315GMT+06; 0345GMT+06:30; 0415GMT+07; 0445GMT+07:30; 0515GMT+08; 0545GMT+08:30; 0615GMT+09; 0645GMT+09:30; 0715GMT+10; 0745GMT+10:30; 0815GMT+11; 0845GMT+11:30; 0915GMT+12; 0945GMT+12:30; 1015GMT+13; 1045GMT+13:30; 1115GMT+14"
The same argument applies to tests format-time-016 and format-time-017, where the width specifier is "6-6" and "5-6" respectively.
Section 9.8.4.2 starts: <quote> 9.8.4.2 Formatting timezones Special rules apply to the formatting of timezones. When the component specifiers Z or z are used, the rules in this section override any rules given elsewhere in the case of discrepancies. </quote> The rules that follow make no mention of the width specifier, and define precriptive output for each option, so one might conclude that the width specifier is ignored. One could also argue that the phrase "If no mechanism is available for fitting the value" is referring to mechanisms described earlier in the same paragraph. 9.8.4.1 does say that timezones should be padded to the minWidth, and I think we can assume that is effective because it doesn't conflict with anything in 9.8.4.2. Conclusion: despite our heroic efforts to clean this up from the XSLT 2.0 version, there is still room for improvement.
The section on width mentions for max-width the special cases, like Nn and the year component. Other cases are not considered special, as long as the value is not changed by that truncation. For min-width, there is a special case, and that's probably why it was included in the section on min-width. I think it makes sense that if min-width applies, that max-width applies as well. But then there is still room for license, because the text allows Tues and Fri, it seems reasonable that both "GMT-05" and "GMT-5" are legal with width 2-6 and 2-5 (but not with 6-6). Or should the widest unpadded value be taken that is allowed by the width-modifier? We could add a rule that says that when the TZ component is requested, that the TZ name, if required, may not be omitted beyond its shortest requested form, i.e., CT, CLT, CLST all denote Chile Standard Time, UTC+04:00. I doubt anyone would want that kind of expressive freedom though. For me, simply truncating as the text appears to allow, seems more than enough.
Re-assigning this bug against the FO spec.
The WG accepted in principle revising the spec to say that the output of the timezone formatting was as defined in section 9.8.4.2, padded if necessary to the required minWidth as described in the penult bullet of 9.8.4.1, but never truncated by virtue of a maxWidth (any maxWidth is ignored)
Thanks, that clears it up. Is this backward applicable to FO30, or is the width modifier still applicable in that version?