Problem statement:

We want to be able to specify that "Z" is to be used instead of
+00:00, but that any other time offset should be presented in its
numeric value.

Some observations on our current text:

a: "Z", instead of "+00:00" should be considered a "name" of a time zone
and thus, potentially,  obtainable by specifying "N" as preentation
modifier. However, all other time offsets would also be presented in
"name" form, e.g. EDT.

b: we can specify a min and max width of the result, but we do not
really say which is preferred, except that that in a "For example, "
that indicates that for names the maximum width should be used.
Thus using [Z,1-6] (width 1 -> "Z", width 6 -> +00:00) does not seem
appropriate.

c: using a specification of [Z,1-1] is also not appropriate as,
for values other than +00:00, it relies on the "last resort" of what
to do if the value does not fit in the width.

It thus seems better to introduce a new presentation modifier,
which needs to express the numeric/name preference AND which
numeric presentation form is to be used (e.g. the offset in Thai digits).

I have been asked (A-2008-10-02-001) to define a proposal to resolve this.

It isn't easy! There are too many potential variations on how users might want to display timezones. For the purpose of an erratum, I'm reluctant to introduce new syntax, and would prefer to issue an interpretation of how the existing syntactic elements should be interpreted. We already have some fairly creative interpretations of how the width specifier should be used for the year and for the fractional seconds, and we have already made use of it in solving bug #5309 which is similar so I propose to use that. (See erratum E24, http://www.w3.org/XML/2007/qt-errata/xslt-errata.html#E24)

Where the component specifier is Z, and the presentation modifier is numeric, I propose that the width specifier be interpreted as follows:

6-6  - always use the form +hh:mm, for example -05:00

1-6  - use Z for UTC, otherwise use the form +hh:mm

other values - effect is implementation-defined

Default: 1-6

Specifically, I suggest in the table entry for component specifier Z, replacing:

<old>
timezone as a time offset from UTC, or if an alphabetic modifier is present the conventional name of a timezone (such as PST)
</old>

by

<new>
* If the presentation modifier is numeric or absent, then timezone as a time offset from UTC, for example -05:00, or Z to represent UTC, subject to the width modifier as described below

* if the presentation modifier is N, n, or Nn, the conventional name of a timezone (such as PST), using timezone names that are customary in the country denoted by the country argument if present, or implementation-defined timezone names otherwise
</new>

Then in the new text introduced by Erratum E24 change 3, replace:

<old>
* For timezone offsets this should be done by first appending a colon (:) followed by two zero digits from the appropriate set of digit characters if the full representation does not already include a minutes component and if the specified minimum width permits adding three characters, and then if necessary prepending zero digits from the appropriate set of digit characters to the hour component.
</old>

by

<new>
* For timezone offsets using the component specifier "z" this should be done by first appending a colon (:) followed by two zero digits from the appropriate set of digit characters if the full representation does not already include a minutes component and if the specified minimum width permits adding three characters, and then if necessary prepending zero digits from the appropriate set of digit characters to the hour component.

* For timezone offsets using the component specifier "Z" with a numeric presentation modifier, this should be done by first replacing the symbol "Z" (denoting UTC) by "+00:00" (omitting the minutes if necessary to fit within the maximum width), then padding with spaces if necessary.
</new>

This was discussed by the WG on 2009-01-29. The consensus was in favour of adding new syntax to give user control over this decision in a future release, and leaving the output implementation-defined (or dependent) in XSLT 2.0.

An Erratum (E29) to XSLT 2.0 will be raised to explain that the specification does not define the output in this case.

This bug report will be left open but recategorized against Functions and Operators 1.1 (which is where format-date() is moving).

Erratum E29 proposes adding the following (non-normative) Note. This is in addition to the normative changes agreed in Erratum E24, raised in response to bug 5309. The note goes beyond the subject of this particular bug to discuss other aspects of timezone formatting that have caused problems in the past, all in a non-prescriptive way.

<note>
  <p>Formatting of timezones is not fully defined by this specification. Some aspects of the formatting
  are <termref def="dt-implementation-dependent">implementation-dependent</termref>.</p>

  <p>For component specifier "z", the choice between "GMT+2" and "GMT+02:00" is guided by the width specifier,
  as indicated above. The string "GMT" may be localized, for example to "UTC". The representation of the UTC
  timezone itself (that is, a timezone offset of zero) is not defined in this specification.</p>

  <p>For component specifier "Z" with a numeric presentation modifier, the implementation may optionally
  use "Z" rather than "+00:00" to indicate UTC.</p>

  <p>Component specifier "Z" with the presentation modifier "N" is used to request timezone names such as
  "PST" or "CET". Translation of a timezone offset into the name of a civil timezone can only be done heuristically.
  The implementation may use the <code>$country</code> argument as a guide to the civil timezones to match
  against; if <code>$value</code> includes a date then the implementation may also use a database of 
  daylight-savings-time changes to distinguish two timezone names, such as "EDT" and "AST", that have the same 
  timezone offset.</p>
</note>

This is now open as a 1.1 bug report, allowing a fresh design approach that can incorporate new facilities while still requiring a good level of backwards compatibility.

The first thing I propose is to generalize the $country argument to be $place, allowing the value to be an Olsen time-zone name. Specifying an Olsen time-zone name has two effects: (a) the supplied date/time is adjusted to that time-zone, (b) the appropriate localized name of the time-zone is used. For example, format-dateTime('2009-01-01T12:00:00Z', '[H]:[M]:[S] [ZN]', (), (), 'America/Los Angeles') produces "04:00:00 PST". In cases where a date is present in the supplied value and the date is within the range where daylight savings time changes are documented, this process should be sensitive to daylight savings, for example if the date above were in summer the output would be "05:00:00 PDT".

If ZN is requested without specifying an Olsen time-zone in the $place argument, the system should use a default Olsen time-zone.

Having put this into place, I suggest we reorganize the display of timezones as follows. First some examples:

[Z01:01] produces +05:00 or -02:00 or +10:30 or Z

[Z1] produces +5 or -2 or +10:30 or Z

[Z1:01[+00:00]] produces +5:00 or -2:00 or +00:00

[Z1:01[UTC]] produces +5:00 or -2:00 or UTC

[Z01:01[]] produces +05:00 or -02:00 or nothing

[ZN] produces EST or CET or GMT etc

[ZZ] produces a military timezone letter: A, B, C, ... Z

The component designator "z", for backwards compatibility, produces the same result as "Z" but prefixed "GMT" (or a localized equivalent)

Specifically: 

(a) where the timezone offset is displayed numerically, two format tokens are allowed, separated by ":", one for the hours and one for the minutes; if the minutes part is not specified, then it is omitted from the output unless the value is non-zero, in which case it is output as ":mm".

(b) the form used to display timezone Z may be given as a literal string between [] characters (and may be empty), the default being "Z". 

Detailed rules to be defined.

At its meeting on 8 December 2009 the WG indicated support in principle for the ideas in comment #5 and gave the author an action to develop this into a concrete proposal. Note spelling Olsen -> Olson.

The proposed resolution is as follows.

1. rename the $country argument as $place, with consequent changes to the places where it is referenced. Change the last paragraph of 9.8.4.2 ("The intended use of the country argument...") to:

<new>
The intended use of the $place argument is to identify where an event represented by the dateTime, date, or time supplied in the $value argument took place or will take place. If the value is supplied, and is not the empty sequence, then it should be either a country code or an Olson timezone name:

* Country codes are defined in [ISO 3166-1]. Examples are "de" for Germany and "jp" for Japan. Implementations may also allow the use of codes representing subdivisions of a country from ISO 3166-2, or codes representing formerly used names of countries from ISO 3166-3. 

* Olson time-zone names are defined in the public-domain tz timezone database (see [http://www.twinsun.com/tz/tz-link.htm]). Examples are America/New_York and Europe/Rome.

This argument is not intended to identify the location of the user for whom the date or time is being formatted; that should be done by means of the language attribute. This information may be used to provide additional information when converting dates between calendars or when deciding how individual components of the date and time are to be formatted. For example, different countries using the Old Style (Julian) calendar started the new year on different days, and some countries used variants of the calendar that were out of synchronization as a result of differences in calculating leap years.

The geographical area identified by a country code is defined by the boundaries as they existed at the time of the date to be formatted, or the present-day boundaries for dates in the future.

If the $place argument is supplied in the form of an Olson time-zone name that is recognized by the implementation, then the date or time being formatted is adjusted to the time zone offset applicable in that time zone. For example, if the dateTime 2010-02-15T12:00:00Z is formatted with the $place argument set to America/New_York, then the output will be as if the value 2010-02-15T07:00:00-05:00 had been supplied. This adjustment takes daylight savings time into account where possible; if the date in question falls during daylight savings time in New York, then it is adjusted to timezone offset -PT4H rather than -PT5H. Adjustment using daylight savings time is only possible where the value includes a date, and where the date is within the range covered by the timezone database.
</new> 

2. Change the description of format designator "z" so that it produces the same output as "Z", except that when the format is numeric, the value is preceded by "GMT" or a localized equivalent: for example +5 becomes GMT+5, while +05:00 becomes GMT+05:00.

3. For format designator "Z", allow a wider range of presentation modifiers, and define their interpretation as follows:

(a) One or two digits to indicate a time offset shown in hours, for example Z1 or Z01 resulting in the output -5 or -05. If the actual timezone offset is not an integral number of hours, the minutes will be added automatically, separated by a colon, for example +10:30.

(b) Two numbers separated by a grouping separator (any non-alphanumeric character, see format-integer() for definition, but not "]") to indicate a time zone offset always shown in hours and minutes, with a defined separator: for example Z01:01 resulting in the output +12:30 or -05:00.

(c) A 3- or 4- digit number with no grouping separator to indicate a time zone offset shown in hours and minutes with no separator, for example Z0001 results in +0500 or -1030.

(d) The value Z to indicate a military timezone (where Z, Zulu time, represents +00:00, A represents +01:00, and so on.) An extra half hour is indicated by an asterisk, for example ZZ causes +11:30 to be output as L*. Time zone offsets that are not multiples of a half hour cannot be represented using this convention.

(e) The value N to indicate a timezone name, such as EST or CET. The same timezone offset has different names in different places: it is therefore *recommended* that this option should only be used if a country code or Olson timezone name is supplied in the $place argument. In the absence of this information, the implementation may apply a default, for example by using the timezone names that are conventional in North America.

The effect of other presentation modifiers and of the width specifier for component Z is implementation-defined.

[Examples illustrating these rules will be added]

Note that the text proposed in comment #7 is now present in the status quo text of the working draft.