This message includes strawman proposals for
(a) a simplified pattern syntax and
(b) simple style specifiers
for DateTimeFormat objects, which can replace the current format specification
through nine separate properties for the components of formatted date and time.
Several people have recently proposed to reintroduce patterns as a way to
specify the format of a DateTimeFormat object, because patterns give user
experience designers precise control over the format and can be stored in
resource bundles for localizability. The Unicode Locale Data Markup Language
provides a comprehensive pattern syntax for date and time formats [1], however,
many of the features of this syntax are rarely used, and it is unlikely that
all implementations of the Globalization API will support all of them. The
proposal below includes the most commonly used pattern elements, and simplifies
the syntax somewhat by relying on existing information about locale behavior.
The reintroduction of patterns also gives us an opportunity to reconsider the
current format specifications as well. The current format specifications give
developers a lot of knobs to play with (nine properties for the different
components of a formatted date and time), giving the impression of precise
control, but in reality they're connected to the underlying engine only via
rubber bands: The implementation has to support only a few combinations of
settings, and has great freedom in choosing its behavior when other
combinations are requested. In addition, despite the large number of
combinations, the format specifications still cannot describe all formats that
are in common use [2]. If patterns give developers a low-level mechanism with
full control over the formats they want to use, then the current format
specifications can be replaced with a high-level mechanism that provides access
to a few pre-made formats that are guaranteed to be supported across
implementations and locales.
[1] http://unicode.org/reports/tr35/#Date_Format_Patterns
[2] https://bugs.ecmascript.org/show_bug.cgi?id=229
Comments?
Regards,
Norbert
DateTimeFormat Pattern Syntax
-----------------------------
All unquoted ASCII letters A-Z, a-z are reserved. To be used as literal text,
they must be in quotes. Other characters can be inserted as needed, e.g.,
punctuation (:, /) or non-ASCII letters (年, 년).
Weekday:
WWW - abbreviated weekday name.
WWWW - full weekday name.
Year:
Y, YY, YYY, YYYY, YYYYY - year represented as number, 0-padded to specified
number of digits. For YY year % 100 is used.
DateTimeFormat may add an era if necessary for the calendar used.
Month:
M, MM - month represented as number, 0-padded to specified number of digits.
MMM - abbreviated month name.
MMMM - full month name.
DateTimeFormat uses embedded or stand-alone month names based on the locale and
the presence of the day component.
Day:
D, DD - day represented as number, 0-padded to specified number of digits.
Period:
aaa - abbreviated day period.
Hour:
h, hh: hour represented as number, 0-padded to specified number of digits.
DateTimeFormat uses 12-hour time if "aaa" is present, 24-hour otherwise; this
can be overridden by the hour12 option. DateTimeFormat uses 0- or 1-based numbers as
appropriate for the locale.
Minute:
m, mm: minute represented as number, 0-padded to specified number of digits.
Second:
s, ss: second represented as number, 0-padded to specified number of digits.
DateTimeFormat Style Specifiers
-------------------------------
The specifiers are strings with two parts, the first indicating the date and
time components included in the format, the second indicating short (numeric),
medium (abbreviated), or long form. Specifiers with weekday, year, month, day
components are used in a dateStyle property of the DateTimeFormat options;
specifiers with hour, minute, second components in a timeStyle property. The
exact mapping from style specifiers to concrete DateTimeFormat patterns is
implementation and locale dependent.
Support required in all implementations:
"WYMD-long": weekday, year, month, day components; long form
"YMD-long": year, month, day components; long form
"YMD-short": year, month, day components; numeric form
"YM-long": year, month components; long form
"MD-medium": month, day components; abbreviated form
"hms-short": hour, minute, second components; numeric form
"hm-short": hour, minute, second components; numeric form
Allowed, but not required; fall back to required formats as specified:
"WYMD-medium": weekday, year, month, day components; abbreviated form;
"WYMD-long"
"YMD-medium": year, month, day components; abbreviated form; "YMD-long"
"hms-medium": hour, minute, second components; abbreviated form; "hms-short"
"hm-medium": hour, minute, second components; abbreviated form; "hm-short"
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
