Formats and parses dates and times using locale-sensitive patterns.
Patterns
| 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.
| Pattern | Common TimeZone | Simple TimeZone |
| z, zz, zzz | PDT | UTC-7 |
| zzzz | Pacific Daylight Time | UTC-7 |
| Z, ZZ, ZZZ | -0700 | -0700 |
| ZZZZ | GMT-07:00 | GMT-07:00 |
| v, vv, vvv, vvvv | America/Los_Angeles | Etc/GMT+7 |
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 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}