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.
Related
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 developing a multi language app.
When none of the supported languages is chosen by the user as its iOS language, I am showing all text in English.
Everything works just fine, except that I also want in this case to have the dates formatted in English.
I know how to force English as the format, but the problem is that I would like this to be generic and I only want to force as English if the language is not supported. If I could tell if the language is a non supported one in a generic way, this would do it.
For instance my app does not currently support Spanish, so it is using the base strings which are in English. However the dates are formatted in Spanish. For instance, the following code in this case will return "ago 2017" instead of "Aug 2017".
NSString* dateFormat = [NSDateFormatter dateFormatFromTemplate:#"MMM yyyy" options:0 locale:nil];
NSDateFormatter* dateFormatter = [[NSDateFormatter alloc] init];
dateFormatter.dateFormat = dateFormat;
NSString* formatedString = [dateFormatter stringFromDate:[Calendar today]];
I'm using following function to create Date from String. It works well on simulator. But it crashed on real iPhone.
String: "Tue May 23 23:19:41 +0800 2017"
The first picture is debugging information on real iPhone. The second one is debugging information on simulator.
func createDate(fromString string: String) -> Date {
let formatter = DateFormatter()
formatter.dateFormat = "EEE MMM dd HH:mm:ss zzz yyyy"
let date = formatter.date(from: string) //fatal error: unexpectedly found nil while unwrapping an Optional value
return date!
}
I even tried it on playground. It's really weird!
Thanks!
this link may solve your problem.....
Swift
formatter.locale = Locale(identifier: "en_US")
I bet it's crashing on the next line, not on the line you've commented. You're force-unwrapping the result. That force-unwrap will crash with the exact error you are reporting if the date conversion fails.
I call the ! operator the "crash if nil" operator. You should not do that. You need to program defensively and return the optional, then write the calling code to handle the case where the conversion fails.
Others have already pointed out that date formatters depend on the locale of the device, and if it's different your conversion could fail. Force the formatter's locale to a known locale if you want to give it literal strings who's format doesn't vary based on country and language.
from the app docs
When working with fixed format dates, such as RFC 3339, you set the
dateFormat property to specify a format string. For most fixed
formats, you should also set the locale property to a POSIX locale
("en_US_POSIX"), and set the timeZone property to UTC.
RFC 3339
In macOS 10.12 and later or iOS 10 and later, use the
ISO8601DateFormatter class when working with ISO 8601 date
representations.
wiki ISO 8601
For proper format, use Date Field Symbol Table
you date format slightly wrong, please use the bellow example dateformat.
let dateString : String = "Tue May 23 23:19:41 +0800 2017"
let dateFormatter = DateFormatter()
dateFormatter.dateFormat = "EEE MMM dd HH:mm:ss ZZZ yyyy"
dateFormatter.timeZone = TimeZone(identifier: "GMT")
print(dateFormatter.date(from: dateString))
I am trying to parse this date timestamp
Begin to string:
Wed, 11 Sep 2013 08:51:41 EEST
This issue with only
EEST
, I have tried z or zzz or V, nothing happened. Date formatter always getting NULL.
While I am cutting EEST from string, everything goes OK.
Could anyone suggest, how to solve this issue?
Thanks
UPDATE:
dateFormat = [[NSDateFormatter alloc] init];
[dateFormat setLocale:[[NSLocale alloc] initWithLocaleIdentifier:#"en_EN_POSIX"]];
[dateFormat setTimeZone:[NSTimeZone timeZoneWithAbbreviation:#"EEST"]];
[dateFormat setDateFormat:#"EEE, dd MMM yyyy HH:mm:ss V"];
dateFromString = [dateFormat dateFromString:beginString];
Your solution to this problem is to change the locale to en_GB and the date formatter will be able to parse your date string properly.
Here is the explanation from the Apple developer bug reporting team in reply to radar #9944011:
This is an intentional change in iOS 5. The issue is this: With the short formats as specified by z (=zzz) or v (=vvv), there can be a lot of ambiguity. For example, "ET" for Eastern Time" could apply to different time zones in many different regions. To improve formatting and parsing reliability, the short forms are only used in a locale if the "cu" (commonly used) flag is set for the locale. Otherwise, only the long forms are used (for both formatting and parsing). This is a change in open-source CLDR 2.0 / ICU 4.8, which is the basis for the ICU in iOS 5, which in turn is the basis of NSDateFormatter behavior.
For the "en" locale (= "en_US"), the cu flag is set for metazones such as Alaska, America_Central, America_Eastern, America_Mountain, America_Pacific, Atlantic, Hawaii_Aleutian, and GMT. It is not set for Europe_Central.
However, for the "en_GB" locale, the cu flag is set for Europe_Central.
So, a formatter set for short timezone style "z" or "zzz" and locale "en" or "en_US" will not parse "CEST" or "CET", but if the locale is instead set to "en_GB" it will parse those. The "GMT" style will be parsed by all.
If the formatter is set for the long timezone style "zzzz", and the locale is any of "en", "en_US", or "en_GB", then any of the following will be parsed, because they are unambiguous:
"Pacific Daylight Time" "Central European Summer Time" "Central European Time"
Try this instead:
NSString *beginString = #"Wed, 11 Sep 2013 08:51:41 EEST";
NSDateFormatter *dateFormat = [[NSDateFormatter alloc] init];
[dateFormat setLocale:[[NSLocale alloc] initWithLocaleIdentifier:#"en-GB"]];
[dateFormat setDateFormat:#"EEE, dd MMM yyyy HH:mm:ss zzz"];
NSDate *dateFromString = [dateFormat dateFromString:beginString];
See details & explanation here
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);