date. One to three letters for the abbreviated form, four letters for the long form, five for the narrow form.

Example:

but for two letters it also specifies the maximum length. This year designation is used in ISO year-week calendar as defined by ISO 8601, but can be used in non-Gregorian based calendar systems where week date processing is desired. May not always be the same value as calendar year.

all supra-year fields. For example, for the Julian calendar system, year numbers are positive, with an era of BCE or CE. An extended year value for the Julian calendar system assigns positive values to CE years and negative values to BCE years, with 1 BCE being year 0.

Chinese lunar calendar (and related calendars) and the Hindu calendars use 60-year cycles of year names. Use one through three letters for the abbreviated name, four for the full name, or five for the narrow name (currently the data only provides abbreviated names, which will be used for all requested name widths). If the calendar does not provide cyclic year name data, or if the year value to be formatted is out of the range of years for which cyclic name data is provided, then numeric formatting is used (behaves like 'y').

quarter, three for the abbreviation, or four for the full name.

for the numerical quarter, three for the abbreviation, or four for the full name.

month, three for the abbreviation, four for the full name, or five for the narrow name.

for the numerical month, three for the abbreviation, or four for the full name, or 5 for the narrow name.

to be used in combination with M to indicate placement of the symbol for leap month in the Chinese calendar. Placement of that marker is now specified using locale-specific <monthPatterns> data, and formatting and parsing of that marker should be handled as part of supporting the regular M and L pattern characters.

First, it demarcates days at local zone midnight, rather than noon GMT. Second, it is a local number; that is, it depends on the local time zone. It can be thought of as a single number that encompasses all the date-related fields.

day

for the short day, or four for the full name, five for the narrow name, or six for the short name.

a numeric value that will depend on the local starting day of the week, using one or two letters. For this example, Monday is the first day of the week.

Use one letter for the local numeric value (same as 'e'), three for the short day, four for the full name, five for the narrow name, or six for the short name.

pattern generation, it should match the 12-hour-cycle format preferred by the locale (h or K); it should not match a 24-hour-cycle format (H or k). Use hh for zero padding.

pattern generation, it should match the 24-hour-cycle format preferred by the locale (H or k); it should not match a 12-hour-cycle format (h or K). Use HH for zero padding.

is reserved for use in skeletons passed to APIs doing flexible date pattern generation. In such a context, it requests the preferred hour format for the locale (h, H, K, or k), as determined by whether h, H, K, or k is used in the standard short time format for the locale. In the implementation of such an API, 'j' must be replaced by h, H, K, or k before beginning a match against availableFormats data. Note that use of 'j' in a skeleton passed to an API is the only way to have a skeleton request a locale's preferred time cycle type (12-hour or 24-hour).

(example shows display using pattern SSSS for seconds value 12.34567)

not including the zone fields. As such, it also reflects discontinuities of those fields on DST transition days. On a day of DST onset, it will jump forward. On a day of DST cessation, it will jump backward. This reflects the fact that is must be combined with the offset field to obtain a unique local time value.

Where that is unavailable, falls back to the short localized GMT format ("O").

Where that is unavailable, falls back to the long localized GMT format ("OOOO").

The format is equivalent to RFC 822 zone format (when optional seconds field is absent). This is equivalent to the "xxxx" specifier.

This is equivalent to the "OOOO" specifier.

-07:52:58

The ISO8601 UTC indicator "Z" is used when local time offset is 0. This is equivalent to the "XXXXX" specifier.

Where that is unavailable, falls back to the generic location format ("VVVV"), then the short localized GMT format as the final fallback.

Where that is unavailable, falls back to generic location format ("VVVV").

Where that is unavailable, the special short time zone ID unk (Unknown Zone) is used.
Note: This specifier was originally used for a variant of the short specific non-location format, but it was deprecated in the later version of this specification. In CLDR 23, the definition of the specifier was changed to designate a short time zone ID.

Where that is unavailable, the localized exemplar city name for the special zone Etc/Unknown is used as the fallback (for example, "Unknown City").

Where that is unavailable, falls back to the long localized GMT format ("OOOO"; Note: Fallback is only necessary with a GMT-style Time Zone ID, like Etc/GMT-830.)
This is especially useful when presenting possible timezone choices for user selection, since the naming is more uniform than the "v" format.

+0530
Z

The ISO8601 UTC indicator "Z" is used when local time offset is 0. (The same as x, plus "Z".)

Z

The ISO8601 UTC indicator "Z" is used when local time offset is 0. (The same as xx, plus "Z".)

Z

The ISO8601 UTC indicator "Z" is used when local time offset is 0. (The same as xxx, plus "Z".)

-075258
Z

The ISO8601 UTC indicator "Z" is used when local time offset is 0. (The same as xxxx, plus "Z".)
Note: The seconds field is not supported by the ISO8601 specification.

-07:52:58
Z

The ISO8601 UTC indicator "Z" is used when local time offset is 0. (The same as xxxxx, plus "Z".)
Note: The seconds field is not supported by the ISO8601 specification.

+0530

-075258

Note: The seconds field is not supported by the ISO8601 specification.

-07:52:58

Note: The seconds field is not supported by the ISO8601 specification.