Improved timezone handling

4 October, 2012 by David Johnstone

The way timezones are handled has changed. Previously, dates and times were shown according to the timezone set in profile settings. Now, dates and times are shown according to the timezone that the ride starts in.

There were a few problems with the old approach, with the main one being that the date of a ride when it is shown may not be the same as the date that it was considered to have when the power profile was generated. Why? The best-for-the-month and best-for-the-year power profiles are calculated ahead of time, and since it doesn’t know what timezone to use (the user can change their timezone), it uses the UTC date, but it’s possible for this to be in the wrong month or even year. For example, if you went for a ride at 7AM on January 1, 2013 in Melbourne (and your timezone is set to Australia/Melbourne, which — including daylight savings — is 11 hours ahead of UTC), the UTC date will be used when adding it to power profiles, and that date is 8PM on December 31, 2012.

The new approach completely avoids this problem by always using the local date. There are a couple of potential problems. Firstly, the wrong timezone might be chosen. This shouldn’t happen, but get in contact if it does. Secondly, this doesn’t work when there is no GPS data for a ride. If this is the case, the user’s timezone (at the time the ride was uploaded) is used.

That’s all for now. Oh, for any software developers reading this, I’ll probably be releasing an open source latitude/longitude to timezone lookup library and a web API in the near future.

This is the blog of Cycling Analytics, which aims be the most insightful, most powerful and most user friendly tool for analysing ride data and managing training. You might be interested in creating an account, or following via Facebook or Twitter.

blog comments powered by Disqus