7 time scenarios every programmer should know about

Image Credit

Last week I wrote about leap seconds and how every programmer should know the difference between UTC, TAI and local time. This week I am going to discuss yet another aspect of time as it relates to software development - the different scenarios in which time is used and how to represent time in each of them.

I'll start with explaining a few related concepts before getting on to the scenarios:

Timezone: I am going to quote Wikipedia's explanation of timezones:

A time zone is a region that observes a uniform standard time for legal, commercial, and social purposes. Time zones tend to follow the boundaries of countries and their subdivisions because it is convenient for areas in close commercial or other communication to keep the same time.

Most of the time zones on land are offset from Coordinated Universal Time (UTC) by a whole number of hours (UTC-12 to UTC+14), but a few are offset by 30 or 45 minutes (for example Newfoundland Standard Time is UTC-03:30, Nepal Standard Time is UTC+05:45, and Indian Standard Time is UTC+05:30). Some higher latitude countries use daylight saving time for part of the year, typically by changing clocks by an hour. Many land time zones are skewed toward the west of the corresponding nautical time zones. This also creates a permanent daylight saving time effect.

DST: DST or daylight savings time is an abomination which has been created by many governments by which the clock is set an hour ahead in summer (to get an extra hour of evening sun time) and an hour behind in winter. In the United States DST occurs at 2:00 AM: in spring the clock is moved forward at 1:59 AM to 3:00 AM resulting in a 23 hour day and in fall the clock is moved behind at 1:59 AM back to 1:00 AM. You can read more about it here.

Now that we've explained the basic terminology, let's get to the scenarios.

Server event time:
As the name suggests this is the time for a server event. However, it comes in two favours. It can either be the time for an event which has just occurred and needs to be timestamped or it could represent the time for a future even that needs to be scheduled. Since, it is usually recommended for a server to have it's clock synchronized with UTC, it is recommended to maintain both these times in UTC as well. However, sometimes servers run daily jobs which need to be run when the traffic is relatively low. You may need to take this into account if your traffic spikes change at different times of the year.

Television show time:
American Idol airs at 9:00 PM on all timezones in their local time. The table which maintains when the show begins probably only needs to store 21:00:00, but the process which needs to actually broadcast the show would need to be timezone aware.

Global meeting time:
A global meeting is a meeting in which people call in from different parts of the world. Typically the time for such a meeting is stored as a time along with the timezone and offset of one location (typically the headquarter) and the attendees calendars will synch up with their offsets. Some developers might attempt to store the time in UTC but that is not a good idea since local offsets can change. For example a meeting which is to be scheduled 3 months from now at 9:00 AM New York time is best saved with the time (9:00:00) and tmezone (New York) instead of converting them to UTC. This is because New York's offset can change as a result of a government decision and the meeting will not be scheduled properly.

Medicine time:
If someone needs to take their medicines at 9:00 AM everyday then they need to take it at that time in the timezone they are in. A CEO who took her vitamins at 9:00 AM when she was in New York would need to take them at 9:00 AM in Paris if she happened to be there the next day. The time for the event itself is saved without any timezone data, but the scheduler itself needs to be aware of the applicable timezone which is usually to be done manually by the user unless the device is capable of automatically switching timezones (either from GPS data, or the mobile signal).

Recurring time:
Recurring time is something which happens periodically (every day, week, month, year). It may sometimes have exceptions, for example a daily meeting might happen only from Monday to Friday, but a daily group meditation session might happen on all days of the week. Recurring time is usually represented as local time: that is the time along with timezone name. However for accuracy the software will always have to synch up the latest timezone file to be aware of any changes made to the timezone offset. As an additional point if the software needs to also record events that have happened then it is a good idea to also store the offset on the day of the event, since these could change in the future.

Relative time:
Relative time is similar to what Twitter shows in its feed: Event X happened 21 minutes ago. For this we only need the UTC time when the event happened along with the current value of the UTC time to get the difference.

Historic time:
Historic time is usually applicable for an event which happened in some part of the world a long time back. Since different parts of the world use different calendars such a time may involve maintaining the time, date, month, year, and calendar.