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
