Polish existing skeleton API.

lib/i18n/date_time_format.dart

Index: lib/i18n/date_time_format.dart
===================================================================
--- lib/i18n/date_time_format.dart	(revision 8224)
+++ lib/i18n/date_time_format.dart	(working copy)
@@ -3,9 +3,14 @@
  * for details. All rights reserved. Use of this source code is governed by a
  * BSD-style license that can be found in the LICENSE file.
  *
- * DateFormat is for formatting and parsing dates in a locale-sensitive 
+ * DateTimeFormat is for formatting and parsing dates in a locale-sensitive 

[Alan Knight, 2012/06/04 19:58:37]

I'd called it DateFormat because the objects it operates on are Dates, and we
don't have either Time or DateTime objects. And it's shorter.

[Emily Fortuna, 2012/06/04 22:25:57]

You're right. I'll fix it right now. 

  * manner. 
- * It allows the user to use any customized pattern to parse or format 
+ * It allows the user to choose from a set of standard date time formats as well
+ * as specify a customized pattern under certain locales. Date elements that
+ * vary across locales include month name, weekname, field, order, etc.
+ * //TODO(efortuna): Customized pattern system -- suggested by i18n needs
+ * // feedback on appropriateness.
+ * We also allow the user to use any customized pattern to parse or format 
  * date-time strings under certain locales. Date elements that vary across 
  * locales include month name, weekname, field, order, etc.
  *
@@ -65,12 +70,12 @@
  *
  *     Format Pattern                         Result
  *     --------------                         -------
- *     "yyyy.MM.dd G 'at' HH:mm:ss vvvv"->> 1996.07.10 AD at 15:08:56 Pacific Time
- *     "EEE, MMM d, ''yy"               ->> Wed, July 10, '96
- *     "h:mm a"                         ->> 12:08 PM
- *     "hh 'o''clock' a, zzzz"          ->> 12 o'clock PM, Pacific Daylight Time
- *     "K:mm a, vvv"                    ->> 0:00 PM, PT
- *     "yyyyy.MMMMM.dd GGG hh:mm aaa"   ->> 01996.July.10 AD 12:08 PM
+ *     "yyyy.MM.dd G 'at' HH:mm:ss vvvv"->1996.07.10 AD at 15:08:56 Pacific Time
+ *     "EEE, MMM d, ''yy"               ->Wed, July 10, '96
+ *     "h:mm a"                         ->12:08 PM
+ *     "hh 'o''clock' a, zzzz"          ->12 o'clock PM, Pacific Daylight Time
+ *     "K:mm a, vvv"                    ->0:00 PM, PT
+ *     "yyyyy.MMMMM.dd GGG hh:mm aaa"   ->01996.July.10 AD 12:08 PM
  *
  * When parsing a date string using the abbreviated year pattern ("yy"),
  * DateTimeParse must interpret the abbreviated year relative to some
@@ -100,51 +105,91 @@
  * that point, the parse of the run fails.
  */
 
-#library('DateFormat');
+#library('DateTimeFormat');
 
-class DateFormat {
+class DateTimeFormat {
 
   /** Definition of this object formats dates. */
   var formatDefinition;
 
-   /** Date/Time format patterns. */
-   // TODO(alanknight): There's a style question of whether to use fullDate or 
-   // FULL_DATE naming conventions.
-   static final int _fullDate = 0;
-   static final int _longDate = 1;
-   static final int _mediumDate = 2;
-   static final int _shortDate = 3;
-   static final int _fullTime = 4;
-   static final int _longTime = 5;
-   static final int _mediumTime = 6;
-   static final int _shortTime = 7;
-   static final int _fullDateTime = 8;
-   static final int _longDateTime = 9;
-   static final int _mediumDateTime = 10;
-   static final int _shortDateTime = 11;
+  /**
+   * String indicating a language code with which the message is to be

[Alan Knight, 2012/06/04 19:58:37]

Strictly I think language would be just the "en" part, and en-US would be a
locale code.

[Emily Fortuna, 2012/06/04 22:25:57]

Done.

+   * formatted (such as en-US).
+   */
+  String _locale;
+
+  /** 
+   * Date/Time format "skeleton" patterns. Also specifiable by String, but
+   * written this way so that they can be discoverable via autocomplete.

[Alan Knight, 2012/06/04 19:58:37]

We should probably say where these come from and/or indicate what the characters
mean. While most are obvious, some are less so, e.g. L, E. Maybe even examples
would be good for the non-i18n literate.

[Emily Fortuna, 2012/06/04 22:25:57]

Done.

+   */
+  static final String Hm = 'Hm';          // HH:mm

[Alan Knight, 2012/06/04 19:58:37]

So usage on these is, e.g.
   new DateTimeFormat(DateTimeFormat.Hms);
?
Are people going to want to type that instead of using the string literal? Is
the case significant on these? Seems like it probably is, but discoverability
would probably be better if all lowercase. But maybe autocomplete doesn't care.
Would named constructors for these be better? Or methods on Intl? e.g.
   new DateTimeFormat.Hms()
or 
   Intl.dateHms();

[Emily Fortuna, 2012/06/04 22:25:57]

Realistically, no, people are not going to want to type that. They're provided
more to be discovered than for extensive use... see page 4 on my User Guide --
they can also be called as intl.date.Hms. I can provide named constructors for
these (in addition??) if that would be better (seems like it would).

+  static final String Hms = 'Hms';        // HH:mm:ss 
+  static final String M = 'M';            // L
+  static final String MEd = 'MEd';        // E, M/d
+  static final String MMM = 'MMM';        // LLL
+  static final String MMMEd = 'MMMEd';    // E, MMM d
+  static final String MMMMEd = 'MMMMEd';  // E, MMMM d
+  static final String MMMMd = 'MMMMd';    // MMMM d
+  static final String MMMd = 'MMMd';      // MMM d
+  static final String Md = 'Md';          // M/d
+  static final String d = 'd';            // d
+  static final String hm = 'hm';          // h:mm a
+  static final String ms = 'ms';          // mm:ss
+  static final String y = 'y';            // yyyy
+  static final String yM = 'yM';          // M/yyyy
+  static final String yMEd = 'yMEd';      // EEE, M/d/yyyy
+  static final String yMMM = 'yMMM';      // MMM yyyy
+  static final String yMMMEd = 'yMMMEd';  // EEE, MM d, yyyy
+  static final String yMMMM = 'yMMMM';    // MMMM yyyy
+  static final String yQ = 'yQ';          // Q yyyy
+  static final String yQQQ = 'yQQQ';      // QQQ yyyy
+
+  /** Date/Time format patterns. */

[Alan Knight, 2012/06/04 19:58:37]

We should probably make this mechanism more consistent with the skeletons.

[Emily Fortuna, 2012/06/04 22:25:57]

Fixing...

+  // TODO(alanknight): There's a style question of whether to use fullDate or 
+  // FULL_DATE naming conventions.
+  static final int _fullDate = 0;
+  static final int _longDate = 1;
+  static final int _mediumDate = 2;
+  static final int _shortDate = 3;
+  static final int _fullTime = 4;
+  static final int _longTime = 5;
+  static final int _mediumTime = 6;
+  static final int _shortTime = 7;
+  static final int _fullDateTime = 8;
+  static final int _longDateTime = 9;
+  static final int _mediumDateTime = 10;
+  static final int _shortDateTime = 11;
     
   /**
    * Named constructors for each of the above values.
    * These could probably be made shorter if we just set the format to the 
    * constant and the parsing was lazy.
    */
-  DateFormat.fullDate() : this.formatDefinition = _fullDate;
-  DateFormat.longDate() : this.formatDefinition = _longDate;
-  DateFormat.mediumDate() : this.formatDefinition = _mediumDate;
-  DateFormat.shortDate() : this.formatDefinition = _shortDate;
-  DateFormat.fullTime() : this.formatDefinition = _fullTime;
-  DateFormat.longTime() : this.formatDefinition = _longTime;
-  DateFormat.mediumTime() : this.formatDefinition = _mediumTime;
-  DateFormat.shortTime() : this.formatDefinition = _shortTime;
-  DateFormat.fullDateTime() : this.formatDefinition = _fullDateTime;
-  DateFormat.longDateTime() : this.formatDefinition = _longDateTime;
-  DateFormat.mediumDateTime() : this.formatDefinition = _mediumDateTime;
-  DateFormat.shortDateTime() : this.formatDefinition = _shortDateTime;
+  DateTimeFormat.fullDate() : this.formatDefinition = _fullDate;
+  DateTimeFormat.longDate() : this.formatDefinition = _longDate;
+  DateTimeFormat.mediumDate() : this.formatDefinition = _mediumDate;
+  DateTimeFormat.shortDate() : this.formatDefinition = _shortDate;
+  DateTimeFormat.fullTime() : this.formatDefinition = _fullTime;
+  DateTimeFormat.longTime() : this.formatDefinition = _longTime;
+  DateTimeFormat.mediumTime() : this.formatDefinition = _mediumTime;
+  DateTimeFormat.shortTime() : this.formatDefinition = _shortTime;
+  DateTimeFormat.fullDateTime() : this.formatDefinition = _fullDateTime;
+  DateTimeFormat.longDateTime() : this.formatDefinition = _longDateTime;
+  DateTimeFormat.mediumDateTime() : this.formatDefinition = _mediumDateTime;
+  DateTimeFormat.shortDateTime() : this.formatDefinition = _shortDateTime;
   
-  DateFormat(this.formatDefinition);
+  /**
+   * Constructor accepts a [formatDefinition], which can be a String, one of the
+   * predefined static forms, or a custom date format using the syntax described
+   * above. An optional [_locale] can be provided for specifics of the language
+   * locale to be used, otherwise, we will attempt to infer it (acceptable if
+   * Dart is running on the client, we can infer from the browser).
+   */
+  DateTimeFormat(this.formatDefinition, [this._locale]);
 
   /**
-   * 
+   * Given user input, attempt to parse the [inputString] into the anticipated
+   * format.
    */
   String parse(String inputString) {
     return inputString;