Rails Ruby on Rails

Comments and changes to this ticket

• 

  Michael Koziarski August 3rd, 2009 @ 01:25 AM

  • 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.

• You flagged this item as spam.
  

  Ryan McGeary August 3rd, 2009 @ 02:13 AM

  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.)

• 

  Michael Koziarski August 3rd, 2009 @ 02:19 AM

  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.

• You flagged this item as spam.
  

  Ryan McGeary August 3rd, 2009 @ 02:53 AM

  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.

• 

  Michael Koziarski August 3rd, 2009 @ 03:03 AM

  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 :/

• 

  Ryan McGeary August 3rd, 2009 @ 05:46 PM

  • no changes were found...

  • better_time_zone_offset_defaults.diff 9.1 KB
• 

  Geoff Buesing August 4th, 2009 @ 04:17 AM

  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)"