Recently, I discovered the issue of timezones particularly when your iOS devices traverses across them. And, after a series of development-testing-iterative headaches, I now find myself more compelled to support a more simplified two-timezone approach for the states.
Here was my problem: I built an app that queries for the “video of the day”, but day needs to be relative to the device’s location. So, after reading through the Apple documentation on timezones and date formatting, I generally assumed the [NSTimeZone systemTimeZone] was exactly what I needed, which is defined as:
The time zone currently used by the system. If the current time zone cannot be determined, returns the GMT time zone.
Perfect, and as I developed on the simulator and on my device, the date was specific to Mountain Standard Time and the API calls worked great.
Then, when we released the app, everything seemed to work fine… until we had users flying across timezones and their devices were pulling down objects with respect to their new locations. That’s when I stumbled upon this great Stack Overflow discussion, and I learned two important things:
- 1. If you have a object instantiated from the [NSTimeZone systemTimeZone], it will be cached by the application and will not reflect the current device’s zone until you clear it using [NSTimeZone resetSystemTimeZone].
- 2. Use [NSTimeZone localTimeZone] instead of [NSTimeZone defaultTimeZone] if you want your timezone variable to reflect any updates to the application’s timezone.