Time Clocks Banner Blog Image

Time is Money

Ren Weishar, Developer, Developer

Now more than ever business is conducted on a multinational stage. The web allows organizations to do business with one another over great distances instantaneously, but with this ease of communication comes a new set of challenges. Simply put, it just can't be the same time everywhere.

In The Zone

A customer in Madrid may be shopping on your online store in the afternoon while you are just starting your busy day in the US. Naturally, a customer wants the date and time on their purchase receipt to reflect the local date and time they made the purchase, not that of the store's. The world is split into 24 distinct time zones to solve problems like this. With the customer's time zone information, all records can be presented with the expected local dates and times anywhere in the world.

Seems simple, right? It is— except for a few pitfalls which could end up costing your business time and money.

Put A Stamp On It

On the web, time zones often come into play when dealing with timestamps on data stored in a database. In most database-driven applications, records are timestamped with the times the entry was created and modified. Nearly all database schemes employ this or similar techniques to keep track of data as it evolves through time— set the created and modified timestamps to the current date and time upon creation, and update the modified timestamp when the data changes.

Simple enough, except for one caveat: what to use for “the current date and time?” One option would be to pick an arbitrary time zone, sometimes simply the time zone the developer happens to reside in— or even worse, the time zone the production server defaults to. Neither is a very good choice, and you'll see why shortly. So what time zone should you use to keep track of data? UTC.

It's Called 'Universal' For A Reason

UTC, or Coordinated Universal Time, is a widely-agreed upon standard measure of time. As mentioned earlier, you can use any time zone you wish when timestamping data. Now as an example, say we're designing our online store to sell to people all over the world. A customer from Australia will require a different date and time on their invoice than one in Europe. The seemingly simple solution is to store the customer's time zone along with their profile and do the conversion when displaying date time information.

What we are doing in the aforementioned scenario is not optimal since we're storing time zone information twice: once when setting the server's time zone to PST, and again by storing time zones with each customer profile. The net result is more frequent and more complicated date time calculations. To simplify, store all data using UTC instead of PST. The advantages of always using UTC are twofold: all time zones are defined as offsets of UTC, so you will most likely be converting to it anyway to do calculations; and POSIX time (which can be retrieved from most operating systems) is defined in UTC.

With a little careful planning, we have saved the development team many frustrating hours of unnecessary, and potentially error prone, time stamp conversions. Here at Lunar Logic, we regularly employ the aforementioned scheme and it has been met with great success, saving us both time and money.

Image Credit:
Are You Ready to Start Your Project?