Package com.google.gwt.i18n.client

Class DateTimeFormat

java.lang.Object
com.google.gwt.i18n.shared.DateTimeFormat
com.google.gwt.i18n.client.DateTimeFormat
public class DateTimeFormat extends DateTimeFormat
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 -0700 -0700
ZZZ -07:00 -07:00
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 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 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

public class DateTimeFormatExample implements EntryPoint {

  public void onModuleLoad() {
    Date today = new Date();

    // prints Tue Dec 18 12:01:26 GMT-500 2007 in the default locale.
    GWT.log(today.toString());

    // prints 12/18/07 in the default locale
    GWT.log(DateTimeFormat.getShortDateFormat().format(today));

    // prints December 18, 2007 in the default locale
    GWT.log(DateTimeFormat.getLongDateFormat().format(today));

    // prints 12:01 PM in the default locale
    GWT.log(DateTimeFormat.getShortTimeFormat().format(today));

    // prints 12:01:26 PM GMT-05:00 in the default locale
    GWT.log(DateTimeFormat.getLongTimeFormat().format(today));

    // prints Dec 18, 2007 12:01:26 PM in the default locale
    GWT.log(DateTimeFormat.getMediumDateTimeFormat().format(today));

    // A custom date format
    DateTimeFormat fmt = DateTimeFormat.getFormat("EEEE, MMMM dd, yyyy");
    // prints Monday, December 17, 2007 in the default locale
    GWT.log(fmt.format(today));
  }
}
deprecated use DateTimeFormat instead