Nsdateformatter +时区问题 [英] Nsdateformatter + Timezone issue

查看:139
本文介绍了Nsdateformatter +时区问题的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我试图解析这个日期时间戳
开始字符串:

I am trying to parse this date timestamp Begin to string:


Sep 2013 08:51:41 EEST

这个问题只有


EEST

EEST

,我试过z或zzz或V,没有发生。日期格式化程序始终为NULL。

, I have tried z or zzz or V, nothing happened. Date formatter always getting NULL.

当我从字符串中剪切EEST时,一切都正常。

While I am cutting EEST from string, everything goes OK.

建议如何解决这个问题?

Could anyone suggest, how to solve this issue?

感谢

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];


推荐答案

您的解决方案是将区域设置更改为 en_GB ,日期格式化程序将能够正确解析您的日期字符串。

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.

开发人员错误报告小组回复雷达#9944011

Here is the explanation from the Apple developer bug reporting team in reply to radar #9944011:


这是iOS 5中的有意更改。问题是:使用z(= zzz)或v(= vvv)指定的短格式,可能会有很多歧义。例如,东部时间的ET可以应用于许多不同区域中的不同时区,为了提高格式化和解析的可靠性,如果cu(常用)标志被设置为这是开源CLDR 2.0 / ICU 4.8的一个变化,它是iOS 5中的ICU的基础,而这又是基础

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.

对于en语言环境(=en_US),cu标志设置为metazones,如Alaska,America_Central,America_Eastern,America_Mountain,America_Pacific ,

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.

但是,对于en_GB语言环境,cu标志设置为Europe_Central。

However, for the "en_GB" locale, the cu flag is set for Europe_Central.

因此,设置为短时区样式z或zzz和语言环境en或en_US的格式化程序不会解析CEST或CET该区域设置改为设置为en_GB,它将解析这些。

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.

如果格式化程序设置为长时区样式zzzz,并且语言环境是en中的任何一个, en_US或en_GB,则将解析以下任何内容,因为它们是无歧义的:

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"

这篇关于Nsdateformatter +时区问题的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆