Code:
DateTimeFormat dateFormat = DateTimeFormat
.getFormat("EEE MMM dd HH:mm:ss zzz yyyy");
Date date = dateFormat.parse("Wed May 30 18:33:22 PDT 2012");
Result:
Uncaught java.lang.IllegalArgumentException: Wed May 30 18:33:22 PDT 2012
Why?
I've checked and doublechecked my pattern against the docs. Plugging the pattern into a SimpleDateFormat tester gives the expected results as well, although that's obviously not a conclusive test.
Parsing of the date has limited support as per the docs you mentioned:
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.
More specifically
In the current implementation, timezone parsing only supports
GMT:hhmm, GMT:+hhmm, and GMT:-hhmm.
So, the following code works fine:
DateTimeFormat dateFormat = DateTimeFormat
.getFormat("EEE MMM dd HH:mm:ss zzz yyyy");
Date date = dateFormat.parse("Thu May 31 09:45:21 GMT-07:00 2012");
GWT.log("Date "+date);
Related
I'd like to ask for some help understanding what might cause my DateFormatter to fail...
App receives data from server as string (ex. "2020-12-13 02:54:36 UTC")
App parses string to date
App supports English and Spanish localisations (irrelevant?)
Code:
DateFormatter (all setup):
dateFormat = "yyyy-MM-dd HH:mm:ss zzz"
generally all dates are returned in UTC but using 'zzz' to also cover other time formats like CDT etc.. we had some mix up on sever side at one point...
Problem:
I've received a single log from a user (using Spanish locale) who experienced date parser failure. But i can't reproduce this anyhow... (phone set to EN / ES - dates parse ok for both UTC and CDT time zones).
Server Response:
{ "creation_date":
"2021-05-14 06:07:55 UTC", }
where date(from string:) returns nil for above date(s).
Am I doing this wrong?
Improvements? (i.e. would setting formatter.locale = "en_EN" help? Server date format is fixed.
Tried to convert from UTC to BST (British summer time) using date format. But it's gives me 'Z' at the end of the date. It is working for from UTS to IST conversation.Below is my code.
NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init];
[dateFormatter setLocale:[NSLocale currentLocale]];
[dateFormatter setDateFormat:#"dd'-'MM'-'yyyy HH':'mm':'ss ZZZZZ"];
NSMutableString *dateString = [NSMutableString stringWithFormat:#"%#", [dateFormatter stringFromDate:[NSDate date]]];
NSLog(#"%#",dateString); // This prints 20-11-2019 12:49:02 Z
Can any one know why does this happen. Any issue with the code or need to change something?
Replace the ZZZZZ in your date format with xxxxx. The use of ZZZZZ will give -99:99 unless the user is in the GMT timezone in which case it simply gives Z. xxxxx will give -99:99 regardless the user's timezone.
You can see specific details in the Unicode specification.
For ZZZZZ it states:
-08:00
-07:52:58
The ISO8601 extended format with hours, minutes and optional seconds fields. The ISO8601 UTC indicator "Z" is used when local time offset is 0. This is equivalent to the "XXXXX" specifier.
For XXXXX it states:
-08:00
-07:52:58
Z
The ISO8601 extended format with hours, minutes and optional seconds fields. The ISO8601 UTC indicator "Z" is used when local time offset is 0. (The same as xxxxx, plus "Z".)
For xxxxx it states:
-08:00
-07:52:58
The ISO8601 extended format with hours, minutes and optional seconds fields. (The same as XXXXX, minus "Z".)
I am trying to convert date from rails api to NSDate object.
The response date from api is 2014-11-05T16:29:09.614Z
What does .614Z mean?
The int before the Z are the milliseconds, the Z stand for Zulu which is the time zone:
From http://en.wikipedia.org/wiki/Coordinated_Universal_Time:
The UTC time zone is sometimes denoted by the letter Z—a reference to
the equivalent nautical time zone (GMT), which has been denoted by a Z
since about 1950. The letter also refers to the "zone description" of
zero hours, which has been used since 1920 (see time zone history).
Since the NATO phonetic alphabet and amateur radio word for Z is
"Zulu", UTC is sometimes known as Zulu time.
Thus you time format is:
NSDateFormatter *formatter = [[NSDateFormatter alloc]init];
[formatter setDateFormat:#"yyyy-MM-dd'T'HH:mm:ss.SSSZ"];
If you include the Z like in the example above the date will correctly converted to the devices current timezone.
A mouthful: when I pass the date "Tue, 15 Jan 2013 11:18:57 -0800" into an NSDateFormatter with the pattern string #"EEE, dd MMM yyyy HH:mm:ss ZZZ" when my Region Format is set to "United States", it works fine.
When I do exactly the same thing—with the exception that my Region Format is set to Germany—it can't parse it.
Any idea why this is so?
The locale of the dateFormatter will be set to the currentLocale of the device, so you'll need to set it to the same region as the date you're trying to format.
NSLocale *locale = [[NSLocale alloc] initWithLocaleIdentifier:#"en_US_POSIX"];
[dateFormatter setLocale:locale];
Just a guess: If the region format is set to German names of days are translated to German, too.
I would try to check if it is possible to parse "Die, 15 Jan 2013 11:18:57 -0800" with German region format.
When UTC date is formatted by DateFormat#format(), I expect to get a String of UTC date formatted, but not.
Please look at the code below. These tests are passed.
My question is why does DateFormat#format() return a time of 12:00 past UTC date? What am I missing here?
Date date(int millisecondsSinceEpoch, bool isUtc) =>
new Date.fromMillisecondsSinceEpoch(millisecondsSinceEpoch, isUtc:isUtc);
DateFormat df = new DateFormat("yyyy-MM-dd hh:mm");
// JST (+9.00)
expect(date(0, false).toString(), equals("1970-01-01 09:00:00.000"));
expect(df.format(date(0, false)), equals("1970-01-01 09:00"));
expect(date(0, true).toString(), equals("1970-01-01 00:00:00.000Z"));
// Why 12 o'clock?
expect(df.format(date(0, true)), equals("1970-01-01 12:00"));
Your format string you've written uses lowercase hh which is a 12 hour clock. Use uppercase HH for the hours to get a 24-hour clock. The output you are getting in the last line is currently saying 12 midnight, rather than 00 hours in a 24-hour clock.
See the explicit pattern syntax in DateFormat