About a year ago, I wrote a feature for JIRA during my 20% time that shipped in JIRA 5.1. This feature notifies a user if their current time zone (as detected by their browser) doesn’t match the time zone they’ve set in their user preferences. Part of the reason I wrote the time zone detection plugin was that, although the time zone setting for users was the headline feature of JIRA 4.4, I didn’t think it was obvious enough to those users who don’t read the release notes or marketing blogs. This meant there might be a significant number of users who were frustrated that JIRA wasn’t displaying times and dates that were meaningful to them, without realizing that they could change the setting. Out of curiosity, just before my plugin went live on our primary customer-facing JIRA instance (jira.atlassian.com), I got some anonymous database stats from the server about how many users had set their time zones. Now, one year later, jira.atlassian.com is running JIRA 6.0 and I got the same (completely anonymous) user stats as before to see if the plugin made a difference. Survey says? It sure did. Stats and graphs and rock ‘n’ roll JAC was upgraded to JIRA 4.4 (and therefore got time zone support) in July 2011. In the 11-ish months between then and its upgrade to 5.1 (with the time zone detection plugin), only 483 users (0.66 percent) had set their time zone. Of these users, over 20 percent were in Sydney, and most likely Atlassian staff. As of my recent data collection, 8,339 users (8.4 percent) have a custom time zone. In raw numbers it’s a 7,856 individual user increase, or 16 times the previous count. Some numbers: A year ago Now Active users 73,493 99,296 Users with a custom time zone 483 (0.66%) 8,339 (8.4%) New users since data was collected last year 25,803 New users with a custom time zone 2,259 (8.75%) Existing users with a custom time zone 6,080 For those who prefer numbers in shiny graph form… So what does this mean? Firstly it reaffirms that feature discovery is important. Users on our primary public JIRA instance running 5.0 hadn’t realized that they’d been able to change their time zone for two major release cycles. But as soon as they had a simple, obvious, one-click solution to set that preference, more than 6,000 of those existing users used the feature. But wait! How do we know that the users weren’t just setting it manually? Was it just a coincidence of timing? No, and here’s why: The plugin uses the open source JS Timezone Detect library to do an in-browser “best guess” about the user’s time zone. Therefore, anyone in Western Europe in the GMT+1 time zone (GMT+2 in summer) gets their time zone detected as “Europe/Berlin” — it’s not 100 percent geographically accurate, but the relative times are the same, so there’s no real user impact (unless there are geo-political aspects to the situation). Looking at the database again, what’s the most-used time zone? “Europe/Berlin,” by quite a margin. It accounts for 91 percent of […]
Previous Topic
