Web Developers: Harmonise Your Time Zones

How it's all too easy to wind up with divergent time zones across a modern web stack

This article is part of my Confessions of an Unintentional CTO book, which is currently available to read for free online.

I’d like to share a short lesson about something that has caused me hassle over the past few years: failure to be thorough in ensuring that the time zones in all my software components match.

Time zones potentially exist in many layers of your stack: your server’s operating system; your database(s); each of your programming languages; your web application itself; the collaborating services under your control (e.g. your other servers or logging solutions); and finally, within all the third-party collaborating software services, such as analytics, mailing list managers, payment providers, and advertising services. Forgetting to sync up the time zones in every one of these different software components stymies the reliability of your data; no longer can you rely on timestamps when working across multiple layers. This makes both debugging and tracking conversions a lot more complicated than need be.

With that in mind, decide your time zone on day one and promise yourself you’ll never connect any other software components to your stack without first setting their time zones. Then finish it all off by sticking your preferred time zone in your README for all to see.


More Articles: Click here for full archive

Dealing with Test Leakage

Strategies for pinpointing and extricating indeterminacy from software tests.


Tips for Programming Accounting Features in Web Apps

Learn about representing money, rounding algorithms, and anticipating oddball transactions.


Replayability

Why your code should be capable of remembering and replaying inputs in the event that something goes wrong