Ramiro Franco

TZ Tactics.

Written on Friday June 7, 2013 at 8:30 a.m.

Timezones. For the most part, I like and agree with their purpose. They help maximize the amount of time people spend awake during the day, keeping them less prone to seasonal affective disorder, and saving power for homes and businesses, in turn using less fossil fuels.

My issue with timezones lies in programming, where they are a minefield of problems waiting to happen, and yesterday my coworkers and I managed to blow up a few of them.

The first issue we stumbled on was relatively minor, everything just seemed to be an hour off when it involved daylight savings time. We seemed to have it fixed, until our app went into staging, where all of our times were now around ten hours off. What happened? Turned out in local development where all time was local, things behaved as expected, our staging environment are all running on utc, so whatever method we had in place was simply translating time to local machine time.

We did eventually stumble onto a clumsy solution that was astonishingly similar to what it was before. We used a little bit of javascript to trim off timezone data attached to date time objects on the front end, then on the back end, took the users choice of timezone, set that as the time zone in a before_save method, and just parsed a time object from the string sans-offset. It's not pretty at all .. but it works:

If anyone knows of a way to clean that up further, I'd love to hear it, but for the time being this seems to be the only way we can generate a Datetime object in the right time zone in Rails.