Lighthouse has a new layout. Prefer the old one? Return to the old layout, and switch back any time from the link at the top of each page.

This project is archived and is in readonly mode.

Return the most popular TimeZone given a UTC offset

#2985

Regarding ActiveSupport::TimeZone, when looking up a time zone from a UTC offset, the returned value is rarely what is expected. Offsets have multiple time zones tied to different places. Currently, the time zone returned happens to be the first one alphabetically for a given offset, which leads to seemingly inconsistent behavior. I think it would be better to return the most popular time zone given each UTC offset.

Current (pre-patch) time zones for different offsets

>> require 'active_support/time'
=> true
>> ActiveSupport::TimeZone[-5].name
=> "Bogota"
>> ActiveSupport::TimeZone[-6].name
=> "Central America"
>> ActiveSupport::TimeZone[-7].name
=> "Arizona"
>> ActiveSupport::TimeZone[-8].name
=> "Pacific Time (US & Canada)"
>> ActiveSupport::TimeZone[0].name
=> "Casablanca"

Examples of proposed time zones for different offsets

>> require 'active_support/time'
=> true
>> ActiveSupport::TimeZone[-5].name
=> "Eastern Time (US & Canada)"
>> ActiveSupport::TimeZone[-6].name
=> "Central Time (US & Canada)"
>> ActiveSupport::TimeZone[-7].name
=> "Mountain Time (US & Canada)"
>> ActiveSupport::TimeZone[-8].name
=> "Pacific Time (US & Canada)"
>> ActiveSupport::TimeZone[0].name
=> "UTC"

I battled with which time zone should be selected for each offset, but I used local population as the deciding factor. When in doubt, the place of highest population is the default.

The attached patch picks a sensible time zone default for each UTC offset. Tests included.

Note: The patch currently picks 'UTC' for offset +0, but 'London' might be a better guess for daylight savings reasons. (Stupid DST)

Justification: I'm auto-sniffing user's time zones based on their browser settings which gives me an offset value. I'd like the guess to be as accurate as possible.

Reported by Ryan McGeary · August 3rd, 2009 @ 12:50 AM

State: wontfix
Milestone: none
Assigned to: nobody
Importance: none

Activity

  1. Michael Koziarski
    Michael Koziarski
    • State changed from new to wontfix

    Sensible is in the eye of the beholder here, application's populations aren't uniformly distributed across the world so we can't use local population.

    I'm not looking to get into another country_select style situation, we'll stick with what we have.

    August 3rd, 2009 @ 01:25 AM

  2. Ryan McGeary
    Ryan McGeary

    Koz, I understand the concern, but a lot of apps guess the wrong time zone for a majority of their users because of the default behavior that's in ActiveSupport. Twitter is one of them.

    If people are offended by picking a time zone based on relative population, then they are probably already pretty offended by picking an arbitrary time zone based on the English alphabet. I say "tough noogies" to them.

    I know it might sound elitist, but Eastern Time (with DST) is a better guess for the majority than America/Bogota (no DST). Applications can still override the defaults just like I'm doing in an existing app (using a custom hash lookup based on populations pulled from WolframAlpha), but improving the defaults helps everyone.

    True, application population probably isn't directly correlated to local population, but it's likely close, and it's about as politically correct as you can get.

    (For the record, I think time zones and, specifically, daylight savings is an abomination. I wish this discussion was moot.)

    August 3rd, 2009 @ 02:13 AM

  3. Michael Koziarski
    Michael Koziarski

    Mapping an offset to a TZ is impossible without some user input, at
    the very least you should be confirming it for them.

    I'd take a patch which made it easier to rejuggle those timezones or
    assign defaults for an offset, but that's all.

    August 3rd, 2009 @ 02:19 AM

  4. Ryan McGeary
    Ryan McGeary

    I'd take a patch which made it easier to rejuggle those timezones or assign defaults for an offset, but that's all.

    That sounds like configuration over convention to me, but I'll give it some thought. Thanks for your time.

    August 3rd, 2009 @ 02:53 AM

  5. Michael Koziarski
    Michael Koziarski

    I realise this sucks from your perspective, but we've had two seperate
    incidents with similar code and frankly I can't take another month of
    hate mail and rage :/

    August 3rd, 2009 @ 03:03 AM

  6. Ryan McGeary
    Ryan McGeary

    August 3rd, 2009 @ 05:46 PM

  7. Geoff Buesing
    Geoff Buesing

    Every app could potentially want different preferred zones, so this sounds like logic that's best left to the app.

    Very easy to implement your own preferred zones, no need to hack the TimeZone class:

    >> PREFERRED_ZONES = {-5 => "Eastern Time (US & Canada)", -6 => "Central Time (US & Canada)"}
=> {-6=>"Central Time (US & Canada)", -5=>"Eastern Time (US & Canada)"}
>> ActiveSupport::TimeZone[PREFERRED_ZONES[-5]].name
=> "Eastern Time (US & Canada)"

    August 4th, 2009 @ 04:17 AM