Formats and parses dates and times using locale-sensitive patterns.

Patterns

c

Symbol	Meaning	Presentation	Example
G	era designator	Text	AD
y	year	Number	1996
L	standalone month in year	Text or Number	July (or) 07
M	month in year	Text or Number	July (or) 07
d	day in month	Number	10
h	hour in am/pm (1-12)	Number	12
H	hour in day (0-23)	Number	0
m	minute in hour	Number	30
s	second in minute	Number	55
S	fractional second	Number	978
E	day of week	Text	Tuesday
c	standalone day of week	Text	Tuesday
a	am/pm marker	Text	PM
k	hour in day (1-24)	Number	24
K	hour in am/pm (0-11)	Number	0
z	time zone	Text	Pacific Standard Time(see comment)
Z	time zone (RFC 822)	Text	-0800(See comment)
v	time zone id	Text	America/Los_Angeles(See comment)
'	escape for text	Delimiter	'Date='
''	single quote	Literal	'o''clock'

The number of pattern letters influences the format, as follows:

Text

if 4 or more, then use the full form; if less than 4, use short or abbreviated form if it exists (e.g., "EEEE" produces "Monday", "EEE" produces "Mon")

Number

the minimum number of digits. Shorter numbers are zero-padded to this amount (e.g. if "m" produces "6", "mm" produces "06"). Year is handled specially; that is, if the count of 'y' is 2, the Year will be truncated to 2 digits. (e.g., if "yyyy" produces "1997", "yy" produces "97".) Unlike other fields, fractional seconds are padded on the right with zero.

Text or Number

3 or more, use text, otherwise use number. (e.g. "M" produces "1", "MM" produces "01", "MMM" produces "Jan", and "MMMM" produces "January". Some pattern letters also treat a count of 5 specially, meaning a single-letter abbreviation: L, M, E, and c.

Any characters in the pattern that are not in the ranges of ['a '..'z'] and ['A'..'Z'] will be treated as quoted text. For instance, characters like ':', ' .', ' ' (space), '#' and ' @' will appear in the resulting time text even they are not embraced within single quotes.

[Time Zone Handling] Web browsers don't provide all the information we need for proper time zone formating -- so GWT has a copy of the required data, for your convenience. For simpler cases, one can also use a fallback implementation that only keeps track of the current timezone offset. These two approaches are called, respectively, Common TimeZones and Simple TimeZones, although both are implemented with the same TimeZone class.

"TimeZone createTimeZone(String timezoneData)" returns a Common TimeZone object, and "TimeZone createTimeZone(int timeZoneOffsetInMinutes)" returns a Simple TimeZone object. The one provided by OS fall into to Simple TimeZone category. For formatting purpose, following table shows the behavior of GWT DateTimeFormat. </p> <table> <tr> <th>Pattern</th> <th>Common TimeZone</th> <th>Simple TimeZone</th> </tr> <tr> <td>z, zz, zzz</td> <td>PDT</td> <td>UTC-7</td> </tr> <tr> <td>zzzz</td> <td>Pacific Daylight Time</td> <td>UTC-7</td> </tr> <tr> <td>Z, ZZ</td> <td>-0700</td> <td>-0700</td> </tr> <tr> <td>ZZZ</td> <td>-07:00</td> <td>-07:00</td> </tr> <tr> <td>ZZZZ</td> <td>GMT-07:00</td> <td>GMT-07:00</td> </tr> <tr> <td>v, vv, vvv, vvvv</td> <td>America/Los_Angeles</td> <td>Etc/GMT+7</td> </tr> </table>

Parsing Dates and Times

The pattern does not need to specify every field. If the year, month, or day is missing from the pattern, the corresponding value will be taken from the current date. If the month is specified but the day is not, the day will be constrained to the last day within the specified month. If the hour, minute, or second is missing, the value defaults to zero.

As with formatting (described above), the count of pattern letters determines the parsing behavior.

Text

4 or more pattern letters--use full form, less than 4--use short or abbreviated form if one exists. In parsing, we will always try long format, then short.

Number

the minimum number of digits.

Text or Number

3 or more characters means use text, otherwise use number

Although the current pattern specification doesn't not specify behavior for all letters, it may in the future. It is strongly discouraged to use unspecified letters as literal text without quoting them.

[Note on TimeZone] The time zone support for parsing is limited. Only standard GMT and RFC format are supported. Time zone specification using time zone id (like America/Los_Angeles), time zone names (like PST, Pacific Standard Time) are not supported. Normally, it is too much a burden for a client application to load all the time zone symbols. And in almost all those cases, it is a better choice to do such parsing on server side through certain RPC mechanism. This decision is based on particular use cases we have studied; in principle, it could be changed in future versions.

Examples

Pattern	Formatted Text
"yyyy.MM.dd G 'at' HH:mm:ss vvvv"	1996.07.10 AD at 15:08:56 America/Los_Angeles
"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, vvvv"	0:00 PM, America/Los_Angeles
"yyyyy.MMMMM.dd GGG hh:mm aaa"	01996.July.10 AD 12:08 PM

Additional Parsing Considerations

When parsing a date string using the abbreviated year pattern ( "yy"), the parser must interpret the abbreviated year relative to some century. It does this by adjusting dates to be within 80 years before and 20 years after the time the parser instance is created. For example, using a pattern of "MM/dd/yy" and a DateTimeFormat object created on Jan 1, 1997, the string "01/11/12" would be interpreted as Jan 11, 2012 while the string "05/04/64" would be interpreted as May 4, 1964. During parsing, only strings consisting of exactly two digits, as defined by {@link java.lang.Character#isDigit(char)}, will be parsed into the default century. If the year pattern does not have exactly two 'y' characters, the year is interpreted literally, regardless of the number of digits. For example, using the pattern "MM/dd/yyyy", "01/11/12" parses to Jan 11, 12 A.D.

When numeric fields abut one another directly, with no intervening delimiter characters, they constitute a run of abutting numeric fields. Such runs are parsed specially. For example, the format "HHmmss" parses the input text "123456" to 12:34:56, parses the input text "12345" to 1:23:45, and fails to parse "1234". In other words, the leftmost field of the run is flexible, while the others keep a fixed width. If the parse fails anywhere in the run, then the leftmost field is shortened by one character, and the entire run is parsed again. This is repeated until either the parse succeeds or the leftmost field is one character in length. If the parse still fails at that point, the parse of the run fails.

In the current implementation, timezone parsing only supports GMT:hhmm, GMT:+hhmm, and GMT:-hhmm.

Example

{@example com.google.gwt.examples.DateTimeFormatExample}

class DateTimeFormat {

 /**
  * Get a DateTimeFormat instance for a predefined format.
  *
  * <p>See {@link CustomDateTimeFormat} if you need a localized format that is
  * not supported here.
  *
  * @param predef {@link PredefinedFormat} describing desired format
  * @return a DateTimeFormat instance for the specified format
  */
 static DateTimeFormat getPredefinedFormat(PredefinedFormat predef) {
   return new DateTimeFormat();
 }

 /**
  * Format a date object using specified time zone.
  *
  * @param date the date object being formatted
  * @param timeZone a TimeZone object that holds time zone information, or
  *     {@code null} to use the default
  *
  * @return string representation for this date in the format defined by this
  *         object
  */
 String format(DateTime date, [TimeZone timeZone = null]) {
   return date.toString();
 }
}

static DateTimeFormat getPredefinedFormat(PredefinedFormat predef) {
 return new DateTimeFormat();
}

{@code null} to use the default

    object

String format(DateTime date, [TimeZone timeZone = null]) {
 return date.toString();
}