| Symbol | Meaning | Presentation | Example |
|---|---|---|---|
G |
era designator | Text | AD |
y |
year | Number | 1996 |
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 |
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 |
Z |
time zone (RFC 822) | Number | -0800 |
v |
time zone (generic) | Text | Pacific Time |
' |
escape for text | Delimiter | 'Date=' |
'' |
single quote | Literal | 'o''clock' |
The number of pattern letters influences the format, as follows:
"EEEE" produces
"Monday", "EEE" produces "Mon")"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."M"
produces "1", "MM" produces "01",
"MMM" produces "Jan", and "MMMM"
produces "January".
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.
This implementation could parse partial date/time. Current date will be used to fill in the unavailable date part. 00:00:00 will be used to fill in the time part.
As with formatting (described above), the count of pattern letters determine the parsing behavior.
Although the current pattern specification doesn't not specify behavior for all letters, it may in the future. It is strongly discouraged to used unspecified letters as literal text without being surrounded by quotes.
| Pattern | Formatted Text |
|---|---|
"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"),
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 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.