DateFormat
Overview
Pattern letters are usually repeated, as their number determines the
exact presentation:
- Text:
For formatting, if the number of pattern letters is 4 or more,
the full form is used; otherwise a short or abbreviated form
is used if available.
For parsing, both forms are accepted, independent of the number
of pattern letters.
- Number:
For formatting, the number of pattern letters is the minimum
number of digits, and shorter numbers are zero-padded to this amount.
For parsing, the number of pattern letters is ignored unless
it's needed to separate two adjacent fields.
- Year:
For formatting, if the number of pattern letters is 2, the year
is truncated to 2 digits; otherwise it is interpreted as a
number.
For parsing, if the number of pattern letters is more than 2,
the year is interpreted literally, regardless of the number of
digits. So using the pattern "MM/dd/yyyy", "01/11/12" parses to
Jan 11, 12 A.D.
For parsing with the abbreviated year pattern ("y" or "yy"),
DateFormat 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 DateFormat
instance is created. For example, using a pattern of "MM/dd/yy" and a
DateFormat instance 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.
Any other numeric string, such as a one digit string, a three or more digit
string, or a two digit string that isn't all digits (for example, "-1"), is
interpreted literally. So "01/02/3" or "01/02/003" are parsed, using the
same pattern, as Jan 2, 3 AD. Likewise, "01/02/-3" is parsed as Jan 2, 4 BC.
- Month:
If the number of pattern letters is 3 or more, the month is
interpreted as text; otherwise,
it is interpreted as a number.
- General time zone:
Time zones are interpreted as text if they have
names. For time zones representing a GMT offset value, the
following syntax is used:
GMTOffsetTimeZone:
GMT Sign Hours : Minutes
Sign: one of
+ -
Hours:
Digit
Digit Digit
Minutes:
Digit Digit
Digit: one of
0 1 2 3 4 5 6 7 8 9
Hours must be between 0 and 23, and Minutes must be between
00 and 59. The format is locale independent and digits must be taken
from the Basic Latin block of the Unicode standard.
For parsing, RFC 822 time zones are also
accepted.
- RFC 822 time zone:
For formatting, the RFC 822 4-digit time zone format is used:
RFC822TimeZone:
Sign TwoDigitHours Minutes
TwoDigitHours:
Digit Digit
TwoDigitHours must be between 00 and 23. Other definitions
are as for general time zones.
For parsing, general time zones are also
accepted.
DateFormat also supports localized date and time
pattern strings. In these strings, the pattern letters described above
may be replaced with other, locale dependent, pattern letters.
DateFormat does not deal with the localization of text
other than the pattern letters; that's up to the client of the class.
Examples
The following examples show how date and time patterns are interpreted in
the U.S. locale. The given date and time are 2001-07-04 12:08:56 local time
in the U.S. Pacific Time time zone.
| Date and Time Pattern
| Result
|
"yyyy.MM.dd G 'at' HH:mm:ss z"
| 2001.07.04 AD at 12:08:56 PDT
|
"EEE, MMM d, ''yy"
| Wed, Jul 4, '01
|
"h:mm a"
| 12:08 PM
|
"hh 'o''clock' a, zzzz"
| 12 o'clock PM, Pacific Daylight Time
|
"K:mm a, z"
| 0:08 PM, PDT
|
"yyyyy.MMMMM.dd GGG hh:mm aaa"
| 02001.July.04 AD 12:08 PM
|
"EEE, d MMM yyyy HH:mm:ss Z"
| Wed, 4 Jul 2001 12:08:56 -0700
|
"yyMMddHHmmssZ"
| 010704120856-0700
|
|
|