Time Zones guide for iOS developers
The development of mobile applications means an implementation of sending and downloading of data. When sending data, an event time that depends on the location must often be included. And here’s where a dilemma occurs – how to correctly send the date and time to a server taking into account the user’s time zone?
All this confusion is caused by the Earth’s rotation, which makes the sun appear at different times in different locations. The consequence of this is the difference of the time in places on Earth distant from each other.
To understand the importance of implementing time standards in an application, we need to start with the vocabulary that relates to the time zones and the confusion they cause.
The most common time zone referenced is UTC (Coordinated Universal Time), a standard for setting time zones in the world. This means that it is not the official time for any of the territories (it is the same for all countries), but it is used to determine the time in the different zones. Time zones in the world are expressed by their negative or positive shift relative to UTC. For example, Dubai is in the GST zone, i.e. UTC + 4, which means that if you are in Dubai and it is 11 am (GST = UTC + 4), according to UTC (UTC = GST – 4) it is now 7 am.
UTC is often mistaken with GMT (Greenwich Mean Time) because in practice their values overlap. GMT (referred to in military circles as Zulu), however, refers to a location designated by the Zero Meridian that passes through Greenwich, therefore it is a time zone for several Eastern European and African countries.
Difference between UTC and GMT timezone
Although UTC and GMT are in practice the same time, the difference between them is as follows:
- GMT is a time zone and a standard describing time, used since the 1970s.
- UTC is a new universally used standard that regulates time around the world, and as with GMT its reference point is time on the Zero Meridian. It is described using atomic time and astronomical time, which refers to Earth’s rotation around its own axis. As it turns out, the rotation of the Earth slows down compared to atomic time, which always passes at the same speed. In order to synchronise both times, it is necessary to add a so-called leap second to atomic time. This is the main difference between the two times.
Example impact of time zones on the mobile industry
To understand the impact of time zones on the mobile industry, let’s use an example. Imagine that you just signed up for a conference in London, which you are flying to from Warsaw. During the break, using your communicator in the event application you arranged one-on-one meetings with Mark Zuckerberg, and then with Larry Kim. Unfortunately, the application that you used does not take into account your local time zones, so the hours for which the meetings are set will be different.
This means that you will never have the opportunity to meet with Mark Zuckerberg and you will return home with your head hanging down – assuming that the airline application also works properly 🙂
You are angry and curse at the app’s developers.
In this article, we will show you what to do to avoid such a situation and not join this cursed group of application developers.
The time in iOS can be written as follows:
- Timestamp e.g. 1507140070.76334, which represents the number of seconds since January 1st, 1970 using UTC
- String, text such as 2017-10-04 20:01:10
- Date – a structure used to represent the date inside the application
Timestamp and string are formats that represent the time. With their use, we can send time to a server, to Android and other platforms.
In Appchance, time is recorded in the form of a string because of its readability (you can see right away if the time is correct).
When performing operations on dates and times in Swift applications, we use the Date structure, which is a specific point in time, independent of the time zone, and does not include time zone information. This structure implements useful Comparable, Equatable protocols, so we can easily compare two dates with each other.
It is worth checking the source code of the date structure: GitHub.
As you can see, time is stored there in the variable
|
1 |
fileprivate var _time : TimeInterval |
Where TimeInterval is really an alias for the Double type.
When we create the present date
|
1 |
let now = Date() |
we call the constructor
|
1 2 3 |
public init() { _time = CFAbsoluteTimeGetCurrent() } |
The CFAbsoluteTimeGetCurrent method returns the current system absolute time. Where absolute time is measured in seconds relative to the absolute reference date of Jan 1 2001 00:00:00 GMT. The date structure thus contains the time represented by the number of seconds elapsed since the reference date (Jan 1 2001 00:00:00) in UTC.
In order to correctly display the time in the user’s time zone, we need an auxiliary class that will convert the time expressed using the date structure to local time.
The DateFormatter class allows us to convert dates from text form to date objects and vice versa. In addition, DateFormatter allows us to define custom formats and easily set time zones (by default, DateFormatter uses the user’s local time zone)
The most common mistake committed by developers is to send local time without attaching the time zone information. Consequently, the recipient does not have enough information to convert the time and adjust it to their time zone. The transmitted time, therefore, works correctly only within one zone.
Let’s say we want to send the current date to the server. We can do this as follows:
|
1 2 3 4 5 6 7 |
func dateToString(fromDate date: Date) -> String { let dateFormatter = DateFormatter() dateFormatter.dateFormat = "yyyy-MM-dd HH:mm:ss" return dateFormatter.string(from: date) } |
The application returns a beautifully formatted current date
2017-10-04 20:11:13 (let’s say it’s in the CEST zone = UTC + 2)
A user from another time zone obtains a date sent to the server via network services.
We read it as a string of characters and convert it into the date structure
|
1 2 3 4 5 6 7 |
func stringToDate(fromString string: String) -> Date? { let dateFormatter = DateFormatter() dateFormatter.dateFormat = "yyyy-MM-dd HH:mm:ss" return dateFormatter.date(from: string) } |
The date created in this manner can be presented to the user by formatting the Date structure with the DateFormatter
|
1 2 3 4 5 6 |
let dateFormatter = DateFormatter() dateFormatter.dateFormat = "yyyy-MM-dd HH:mm:ss" if let date = stringToDate(fromString: stringDate) { print(dateFormatter.string(from: date)) } |
Unfortunately, although the user is in a different time zone, the sender’s local time will be displayed, i.e. “2017-10-04 20:11:13”.
To correctly send a date, it must be reduced to UTC with the time zone information added, as follows:
|
1 2 3 4 5 6 7 8 |
func dateToString(fromDate date: Date) -> String { let dateFormmater = DateFormatter() dateFormmater.timeZone = TimeZone(identifier: "UTC") dateFormmater.dateFormat = "yyyy-MM-dd HH:mm:ss'Z'" return dateFormmater.string(from: date) } |
where ‘Z’ is the symbol representing the GMT zone (short for Zulu).
Assuming that the sender sends the time 2017-10-04 20:11:13 in the CEST time zone (UTC + 2)
we will receive the following date:
2017-10-04 18:11:13Z
The date formatted like this can be safely sent to the server. The application that receives this information must first read the time zone in which the date was saved, then calculate the correct time according to the local zone and present it to the user.
DateFormatter will be helpful here again:
|
1 2 3 4 5 |
func stringToDate(fromString string: String) -> Date? { let dateFormatter = DateFormatter() dateFormatter.dateFormat = "yyyy-MM-dd HH:mm:ssz" return dateFormatter.date(from: string) } |
The ‘z’ character in this case indicates that the time zone is stored in this string
It is worth noting that in this case we use the “z” character and in the previous case we used “Z” – capitalized Z.
Even though it is the same letter, the difference is significant
“z” – is a character informing the DateFormatter that this place in the string will contain information about the time zone, written in a shortened manner
“Z” – specifically means UTC time, adding Z at the end of the time string indicates that this is time in UTC, Z is an acronym for Zulu, i.e. the military term for the Zero Meridian
Because the date structure is unreadable, to convert the date obtained, it must be converted into a string, also converting it to a local time zone:
|
1 2 3 4 5 6 |
let dateFormatter = DateFormatter() dateFormatter.dateFormat = "yyyy-MM-dd HH:mm:ss" if let date = stringToDate(fromString: stringDate) { print(dateFormatter.string(from: date)) } |
If the user is located in Poznań (CEST + 2), the result of this operation will be the time 2017-10-04 20:11:13
If the message was sent to a user in New York, the time zone is EDT = UTC – 4, so the user will receive the following result: 2017-10-04 14:11:13
We have it now!
From the above code we could create the following extensions:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
extension Date { struct Formatter { static let utcFormatter: DateFormatter = { let dateFormatter = DateFormatter() dateFormatter.dateFormat = "yyyy-MM-dd HH:mm:ss'Z'" dateFormatter.timeZone = TimeZone(identifier: "GMT") return dateFormatter }() } var dateToUTC: String { return Formatter.utcFormatter.string(from: self) } } extension String { struct Formatter { static let utcFormatter: DateFormatter = { let dateFormatter = DateFormatter() dateFormatter.dateFormat = "yyyy-MM-dd HH:mm:ssz" return dateFormatter }() } var dateFromUTC: Date? { return Formatter.utcFormatter.date(from: self) } } |
When using dates in mobile applications, we have to be very careful when sending them to the server.
In order to use time which takes the time zone into account, remember to send it in UTC format, and then convert it to your local time zone upon receipt.
If we manage to properly implement time zones, the users of our applications will be able to freely make appointments with people outside their time zone without fear of confusion.
You might also like
Increasing mobile app retention focuses on the users returning…
thx for that guide it’s helped me.