Skip to main content

Programmer's Guide to Dealing With Different Time Zones

All programmers have to deal with times and time zones at some point. 

When your product gets wider, it gets more and more difficult to handle and synchronize time between multiple time zones. Being well-informed beforehand might save some pain in the "head" later.

 I've compiled a few most important tips to take care of when dealing with time zones. The actual list is definitely much bigger. But consider this a start.

Store Time in UTC

Storing local time in the database is okay when your product is small and deals with just one time zone. But when you start dealing multiple time zones and DST(Daylight Saving Time), it gets weirder. Now you have to convert your time to different time zones for different users and you have to maintain all upcoming DST changes. 

Storing time in UTC can save many headaches in the future. The important reason being that the UTC timezone is never affected by DST. So always remember to store time in UTC, and apply the user's timezone when retrieving it from the database.

Store Time Zone (NOT Offset)

When you are storing time in UTC, you'll definitely need to store user's time zone too, so that you can convert it to the user's time zone before displaying it to the user. But make sure to not confuse with time zone and offset.

Time zone and offset are related but different. An offset is just a constant time (eg:+5:30 hours) which can be added or subtracted from UTC time. A time zone(eg: Asia/Kolkata), on the other hand, may or may not have an offset. The offset of a specific time zone might change depending on what the respective governments decide. A time zone also may or may not have a DST setting and can change from time to time

Conclusion: Store time zone (eg: Asia/Kolkata) and not offset (eg: +5:30), because people follow a time zone, not an offset.

Keep your timezone database updated

All this care is useless if you forget to update your time zone database frequently. A time zone database has details about all time zone changes, like when a DST starts for a specific time zone or if the offset is going to change for a time zone and so on. If you delay updating the timezone database, It can lead to irreversible data errors in your database depending on the use case.

UTC is not the ultimate solution!

Yes. You heard it right! UTC is not going to save you everywhere. Say you want to design a birthday reminder. You calculate the UTC timestamp of the next birthday 12 AM and store it in the DB. Works perfect right? Tomorrow the government announces a change in DST, and phew! Your stored time stamp is now wrong.

Do not store time in UTC for:
  • Future date and time
  • Date-only values

More reading

This post is just a tip of the iceberg when dealing with time and time zones. Like I said, consider this a start. There are deeper things to consider. Make sure to do your research before getting your hands dirty.

Comments

Post a Comment

Popular posts from this blog

How to deal with cache stampede in MySQL

The Cache stampede problem (also called dog-piling, cache miss storm, or cache choking) is not a big problem for small scale systems but is a common headache for large scale applications with millions of requests. It has the potential to bring down the entire system in a matter of seconds. What is Cache Stampede Consider an item that is expensive to generate, and is cached. When the cache expires, the application usually regenerates the item and writes to the cache, and continue as normal. Under very high load, when the cached item expires, multiple requests will get a cache miss and all of them will try to regenerate the cache simultaneously, which will cause a high load in the database. Cache Stampede can occur with any cache including MySQL query cache, or any external cache like Redis or Memcached. It is ok to ignore this problem when your application is small scale but very important to address the issues as you scale up.  Cache stampede can be seen as random spikes in the CPU us
Post a Comment
Read more

Design Patterns

Do not reinvent the wheel. Just realign it. When it comes to software world, most design level problems are already solved. Design Patterns are blueprints of these solutions which you can customize and use in your application. Advantages: Tried and tested solutions be experienced developers. It helps improve developer communication. Every developer knows what a 'Singleton' is, right? Common Design Patterns Creational design patterns Abstract Factory Builder Factory Method Object Pool Prototype Singleton Structural design patterns Adapter Bridge Composite Decorator Facade Flyweight Private Class Data Proxy Behavioural design patterns Chain of responsibility Command Interpreter Iterator Mediator Memento Null Object Observer State Strategy Template Method Visitor
Post a Comment
Read more