David Ojeda

Posted on Sep 24, 2020 • Originally published at blog.davidojeda.dev on Sep 23, 2020

4 Time Zone Bugs I Ran Into

#timezones #programming

Software development is hard. Time zones are hard. Dealing with time zones in software development? Yeah, harder.

Here are 4 places where time zones might differ; and 4 personal bug stories for each case. I'll be referring to the same app for each story, the one I work with and maintain in my day-to-day job. This app works with Mexico's City time zone.

Time zone of your app

Your app runs with a default time zone. It's usually the time zone of the server it runs on, but it can be different.

In Java, you can define the time zone of the whole application when it boots. If for some reason you don't want to work with your server's timezone, this is the place to change it.

The bug - Time in Chile off by one hour

The app shows the date of creation of an object in many places. Three of these places were showing different times; two incorrect and one correct.

One error was because I forgot to pass the user's timezone to the date formatter. Quick fix.

The second error was weird. I couldn't identify why, so I compared it with the correct one.

But the third case was only right because the date had been double parsed! Once on the server and a second time on the client (browser).

So none of the three dates were actually correct. WTF?

After some headaches, I learned that each version of Java comes with a time zone data file. This file includes the latest information on the world's time zones, and the Internet Assigned Numbers Authority (IANA) manages it.

Time zone changes happen when governments decide to apply or not to apply daylight saving times (DST).

In 2015, Chile decided to move from seasonal DST to permanent DST, and some JRE releases included this change. But then, in 2016 Chile decided to revert to how it was before; seasonal DST instead of permanent. What was the issue? The app was using one of these JRE releases with an outdated time zone data file.

You can read more about these DST issues with Java here.

Time zone of your server

The operative system defines your server's time zone. I've always used Linux for production servers, and they come with UTC as the default time zone.

If you need to change this time zone, make sure to do it before your application starts or it won't reflect the change.

The bug - App using the wrong default time zone from the server

I was migrating some processes in our build and deployment pipeline. From configuring the app with every deploy to a pre-built AWS Amazon Machine Image (AMI) with HashiCorp's Packer.

One step of the initial configuration was to change the server's time zone to America/Mexico_City, and I was aware of it. So I created a bash script that changed the time zone on the AMI we were going to use. The script worked well when I tested it on a Linux instance. No problem there.

I proceeded to use this AMI in our staging environment and neither I nor my teammates noticed something off. So, to production!

Customer's questions and complaints about dates behaving weird arrived minutes later 😥

The issue? The script that updated the server's time zone was failing silently and I missed double-checking it in the staging environment. The app wasn't using an explicit time zone, so it took the server's. And the server's time zone was UTC by default, and we needed America/Mexico_City. I fixed the script and, to make sure, updated the app's default time zone to the expected one.

Time zone of your database

You can also change your database's time zone. I use AWS Relational Database Service (RDS) and the default time zone is UTC. You can update it from the parameter group of your cluster or individual instance.

The bug - Wrong database time zone

Now I was doing a migration of our database. I anticipated myself by changing the database's time zone to America/Mexico_City because the app and server had it. Every part of the system should be in the same page, right? Wrong!

The database was perfectly okay being in UTC while the app and server were in America/Mexico_City. That's how it worked.

This bug was not as critical as the previous ones because I caught it in our staging environment.

Time zone of your users

If it wasn't enough, each one of your users can have a different time zone, and you have to take that into consideration when showing time sensitive-data.

The bug - Many of them!

I've encountered many bugs related to user's time zones:

Missing time zone in date formatter.
Incorrect time zone selection from the user.
Missing DST time zone options for users to select.
Storing dates with time zone modifications that get parsed again when retrieved.

Time zones are one of the most complicated topics you'll find while developing software. They're complex by themselves, and even more when you throw some code into the mix.

I hope these short stories can help you avoid my mistakes in the future 🙌🏼

Thanks for reading me! 💙