Time Zone Use Cases

Time zones are a tricky thing. Jon Skeet gives a pretty good overview of the horrors (at 20:10).

But besides the inherent complexity of having timezones and DSTs in the first places, and in hope that these things are abstracted from us by our tools (joda-time, noda-time, whatever), we need to use them properly. And I’m not talking about “configuring default timezone for a JVM” type of “properly”.

I’m talking about use-cases involving timezones. Most web applications have registered users. And many web applications need to display time. But even with a jQuery plugin like timeagothat displays “5 hours ago” rather than an exact time, you still need to know the users’ timezones. How do you get it? It’s complicated.

Fortunately, there is this little library (jsTimezoneDetect) that does the job almost perfectly for you. How does it work is beyond the scope of this post, but you can check the code, and then immediately remember Jon Skeet’s talk.

Anyway, the first point is – always obtain your users’ time zone – you will need it. Obtain it on registration and store it (making it configurable in a ‘profile settings’ page), but also do that for unregistered users and store it in their session. Even detect it for registered users and use it for the active session instead of the default, because users tend to change timezones (traveling around with their portable device).

Okay, we’ve covered displaying times to users in their current timezone. Why do we have to store their default timezone then? Because in many cases we need to do something about our users even when they are not logged in. For example – send them regular email updates or even SMS.

I’m mentioning SMS specifically in the light of an airbnb bug that I reported 6 months ago and which is not fixed yet (I happen to like pointing out bugs of popular startups). So, I’m sleeping one night, having disabled my “silent sleep” app, and at 4 in the morning I get an SMS. From airbnb, saying my reservation in 3 days is approaching. Nice.

We all have these scheduled jobs that run every couple of hours and send notifications (via email or SMS) to our users. But if we do not respect their timezone, they will hate us. Not everyone is sending SMS, but some people even have sound for their email notifications. And even if users don’t get woken up during the night, usually marketing people analyze the perfect time to send marketing messages, reminders, newsletters, etc. E.g. “our main group of users is usually commuting to work between 8 and 9, so if we send them the newsletter at 7:40, they will read it”. And that goes to hell if your user is in UTC+3 rather than UTC.

The solution is now obvious – when doing scheduled batch operations with your users’ profiles, always respect their timezone. E.g. if you want to send a notification at a predefined time or time window, for each user check ifcurrentTime.withTimeZone(user.getTimeZone()).equals(sendingTime)

I wouldn’t be writing these obvious things if I haven’t seen them ignored so many times. Time zones are hard (I even couldn’t spell them consistently throughout the post), but let’s try to apply some commons sense to them.