Time management is one of those complex situations where it’s all too easy to make a mistake. The lessons herewith are acquired in Windward Reports’ scheduling system. To begin with, choosing UTC (commonly known as Greenwich Mean Time) is not always the best option. However, many programmers believe that if they store everything in this manner, they will be safe. (This is why, when Congress changed the start of Daylight Savings Time in the United States several years ago, you had to run a hotfix on Outlook to update recurring events.)

From the most fundamental question: what do people mean by time? What does it signify when users say they want something to run at 7:00 am? They usually tell you 7:00 am where they are located, but this isn’t always the case. In other circumstances, they want each “day” to conclude simultaneously, unadjusted for DST, to compare web server statistics accurately. On the other hand, someone who takes medicine at specific times of the day and has it scheduled in their calendar will want it to always be on local time so that a 3:00 pm event does not become 3:00 am after they have traveled halfway around the world.

Here are the three primary use cases (there are a few others, but they can all be handled by the ones listed below):

1. The same (for lack of a better description) absolute time.
2. The time in a specific time zone changes when Daylight Saving Time (DST) is turned on or off (including double DST, which occurs in some regions).
3. The time in your location.

The first is simple to deal with: you just set the time zone to UTC. There will be 24 hours on every day of the year if this is done. It’s worth noting that UTC only matches Greenwich time during standard time. When DST is in effect, Greenwich and UTC are not the same.

The second step necessitates the setting of a time zone and the saving of time. The time zone, not the current offset, is the geographical zone (UTC). In other words, instead of “Mountain Standard Time” or “Mountain Daylight Savings Time,” you save “Mountain Time.” So, regardless of the season, 7:00 am in “Mountain Time” will be 7:00 am in Colorado.

The third has a time zone named “Local Time,” which is comparable to the second. However, to identify when it occurs, it is necessary to know its time zone.

Outlook now offers a way to deal with it. You can also now customize the time zone for each event.

When you go on business trips, you use this to keep track of your flight schedules from one zone to the next. Everything in Outlook is displayed in the local timezone, and it automatically adapts when that time zone changes. When you’re on a trip in a different timezone, the iPhone, on the other hand, has no idea what’s going on and has everything turned off (and when you reside in Colorado, nearly every travel takes you to a different time zone).

How do you deal with this? It’s pretty straightforward. Every moment must be saved in one of two ways:

1. In most cases, even though the data is kept in UTC, it will be set/displayed in local time.
2. In the form of a DateTime and a geographical timezone (local time).

The trick now is deciding which to utilize. Here are some broad guidelines to follow. Additional use cases will require further investigation, but most will fall into one of these categories.

1. UTC is the time when something happens. This one-time occurrence cannot be changed, regardless of how the user wants it shown.
2. When the user specifies UTC as the timezone – UTC.
3. A future event in a specific timezone that the user wishes – DateTime plus timezone. Now, if the change will occur within the next several months (changing time zones typically requires that much notice – though it can be as little as eight days), it may be safe to utilize UTC, but you’ll need to do it at some point, so you should do it in all circumstances. In this situation, you’ll see what you’ve saved.
4. For a planned event, the time zone in which it will occur next – UTC. This is a throughput requirement in which you need to retrieve all “next events” with a runtime before now. Searching against dates is much faster than having to recalculate each one. However, if the rules for a quarterly event have changed, all scheduled events must be recalculated regularly.
5. Recalculation should occur if the user’s timezone changes for events that are on “local time.” And if an event is missed during the transition, it must happen right away.

DateTime in .NET

When you dive into .NET, you’ll need to be able to access two things that the standard library doesn’t:

1. Make a DateTime in any timezone you want. DateTime only supports your local timezone and UTC.

2. Get the UTC for a given date, time, and geographical timezone. This must be adjusted according to the DST standards in effect for that zone on that date.

This situation, fortunately, has a solution. Extensions to the DateTime timezone feature have been open-sourced. This relies on Windows registry settings to complete all computations for each zone; thus, it should always be current.

Browser annoyance

You haven’t figured out how to determine a user’s location when accessing a web application through a browser. The locale can be used to establish the timezone in most nations, but not in the United States (6 zones), Canada, or Russia (11 zones). As a result, you’ll need to ask a user to choose a timezone and update it when they travel.

  <input id=”timezone_offset” type=”hidden” name=”timezone_offset” value=””>

  <script type=”text/javascript”></script>

 document.getElementById(‘timezone_offset’).value = new Date().getTimezoneOffset();

Using that in conjunction with the geolocation suggestion for the IP address shown below will get you close. However, it isn’t perfect. The time offset does not indicate whether you are in Arizona (which, like Hawaii, does not observe daylight savings time) or the Pacific/Mountain (depending on DST). You also rely on enabled javascript, which is the case for 99 percent of users nowadays.

The IP address-based geolocation is likewise suspect. In a hotel in D.C., when you received word that your demo download form was having issues. Based on the geo of the IP address, you pre-populate the form with the city, state, and country. It stated that you were located in Cleveland, Ohio. While typically correct, this is not always the case.

In conclusion, you can utilize the offset and then follow up with the geo of the IP address if there are numerous time zones with that offset (on that particular day). However, It is recommended that the powers include a tz= in the header information provided with an HTML request.