iPhone - 时区便利方法之间的差异
我看到 NSTimeZone
有这些方法:
defaultTimeZone
localTimeZone
systemTimeZone
有人可以简单地向我解释一下这些调用之间有什么区别,以及何时应该使用其中一个而不是另一个?我不明白苹果文档中关于此的任何内容。
I see that NSTimeZone
has these methods :
defaultTimeZone
localTimeZone
systemTimeZone
Can someone explain to me, in simple terms, what the differences are beetween those calls, and when one should be used instead of the other? I don't understand anything inside the Apple docs about this.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
可以肯定的是,文档中的语言有点枯燥,而且名称的相似性可能会令人困惑。我将引用
NSTimeZone
文档 在这里并尝试解释它们:这是设备认为其所在的时区;它通常是自动设置的,然后与设备的物理位置相对应,但如果用户在“设置”应用程序中明确设置了特定时区,那么您将得到该时区。
您的应用程序可以设置自己的时区,以便您可以像设备位于另一个区域一样执行操作,但不会影响系统时区(从而影响其他应用程序)。该设置是通过调用
setDefaultTimeZone:
来执行的。如果您还没有这样做,则此调用与调用systemTimeZone
相同。这就是有点棘手的地方。
localTimeZone
提供的结果与defaultTimeZone
几乎相同。不同之处在于,您从localTimeZone
获取的特定NSTimeZone
实例将始终反映您在应用中对时区所做的设置。您可以调用它一次,保存结果,并始终通过该对象获取当前模拟时区,无论进行什么更改。就好像,当您使用此NSTimeZone
实例时,框架正在为您调用defaultTimeZone
,以确保您始终获得当前值。这是上述内容的几个简短说明。您从
systemTimeZone
返回的NSTimeZone
对象表示您进行调用时的系统时区。如果您再次调用systemTimeZone
,即使用户此后更改了时区,您也会得到相同的时区。您的应用会缓存该值,您必须要求系统使用resetSystemTimeZone
清除它才能获取更新。defaultTimeZone
也会发生类似的情况。当您调用该方法时,您将获得一个始终代表同一时区的对象,即使您稍后调用setDefaultTimeZone:
也是如此。但是,如果您使用从localTimeZone
获取的对象,它将遵循您对默认时区*所做的更改。苹果似乎推荐使用
localTimeZone
:*注意,
localTimeZone
仍然受系统时区的应用级缓存的影响。它只会更改以遵循您的默认时区设置。The language in the docs is a bit on the dry side, to be sure, and the similarity of the names is potentially confusing. I'll quote the
NSTimeZone
docs here and try to explain them:This is the time zone which the device believes it is in; it is often set automatically, and would then correspond to the device's physical location, but if the user has explicitly set a particular time zone in the Settings App, that's what you'll get.
Your application is allowed to set its own time zone, so that you can perform actions as if the device were in another zone, but without affecting the system time zone (and thereby other apps). The setting is performed with a call to
setDefaultTimeZone:
. If you haven't done that, this call is identical to callingsystemTimeZone
.This is where it gets a little bit tricky.
localTimeZone
gives you nearly the same result asdefaultTimeZone
. The difference is that the specificNSTimeZone
instance you get fromlocalTimeZone
will always reflect the setting you've made to the time zone within your app. You can call it once, save the result, and always get the current simulated time zone through that object, no matter the changes made. It is as if, when you use thisNSTimeZone
instance, the framework is callingdefaultTimeZone
for you, to be sure that you always get the current value.Here's a couple of brief illustrations of the above. The
NSTimeZone
object that you get back fromsystemTimeZone
represents the system time zone at the time you make the call. If you callsystemTimeZone
again, even if the user has since changed the time zone, you will get the same one. Your app caches that value, and you have to ask the system to clear it withresetSystemTimeZone
to get the update.A similar thing happens with
defaultTimeZone
. When you call that method, you get an object that will always represent the same time zone, even if you later callsetDefaultTimeZone:
. However, if you use the object you get fromlocalTimeZone
, it will follow the change you make to the default time zone*.Apple seems to recommend using
localTimeZone
:*Note that
localTimeZone
is still subject to the app-level cache of the system time zone. It only changes to follow your setting of the default time zone.