[TZInfo-users] selection of select popup based on browser timezone?

Philip Ross philip at ross.org.uk
Thu Jun 15 16:06:56 EDT 2006


Sanjay Vakil wrote:
> First off, thanks so much for doing this.  It just dropped in.  It
> made me happy in the way that ruby itself does.
> 
> My question is:
> 
> I'm using this line to create my selection popup
> 
> 
> <%= time_zone_select 'user', 'time_zone',
>      TZInfo::Timezone.us_zones, :model => TZInfo::Timezone %>
> 
> Is there some clever way to have it default (if otherwise unset) the
> the TZ reported by the browser?  I know that there is javascript out
> there to grab the TZ info (or at least an offset).  it'd be slick if
> the top n entries corresponded to possible (correct) timezones.

Michael Smedberg has done something similar to what you are trying to 
achieve. He's given me permission to distribute his solution to the 
problem. The attachments referenced can be found in 
http://philross.co.uk/files/tzinfo/offset_js.zip


---------- Forwarded message ----------
From: Michael Smedberg <smedberg at gmail.com>
Date: 06-May-2006 01:05
Subject: Re: Question/suggestion related to TZInfo
To: Philip Ross <phil.ross at gmail.com>


I made some minor changes to that file.  I switched from some less 
generic timezone identifiers (like "America/Los_Angeles") to more 
generic (like "US/Pacific".)

I thought your other user might want the same thing, so I've attached 
the latest version of my file... (tz2.js)


---------- Forwarded message ----------
From: Michael Smedberg <smedberg at gmail.com>
Date: 02-Nov-2005 03:19
Subject: Re: Question/suggestion related to TZInfo
To: Philip Ross <phil.ross at gmail.com>


I did something similar to what you suggest.

  You outlined two major problems.  First, looking up timezones by 
offset is slow.  Second, looking up timezones by offset is 
non-deterministic.

  I think I solved these problems (in a relatively cheesy way.)

  Basically, I wrote some code that runs through TZInfo::Timezone.all 
and lists all the timezones and their offsets.  Then I group those with 
the same offset.  For each group, I choose a "most likely" choice, based 
on how many hits Google generates for that timezone (on the theory that 
the most popular timezones would be mentioned on the Web the most 
often.)  Then I simply map offsets to the most likely timezone based on 
a big switch statement (more or less.)

  I've attached this code as tzinfo_extra.rb

  After writing this, I realized that I really want to do this on the 
client side.  When a user signs up for an account I want to show a 
time_zone_select select control, and I want it pre-selected to the most 
likely timezone.  So I took the Ruby stuff and converted it to some 
terse JavaScript.

  I've attached this code as tz.js.

  I'm using SaltedLoginGenerator, and I added the timezone stuff to the 
_edit partial for User.  Here's how I call the JavaScript in that partial:

  <div class="user_edit">
    <%= form_input :hidden_field, 'form', :value => 'edit' %>

    <table>

      <%= form_input changeable(user, "name"), "name" %>
      <%= form_input changeable(user, "login"), "login", :size => 30 %><br/>
      <%= form_input changeable(user, "email"), "email" %>
      <%= time_zone_select 'user', 'time_zone', 
TZInfo::Timezone.all.sort, :model => TZInfo::Timezone %>
      <% if submit %>
        <%= form_input :submit_button, user.new_record? ? 'signup' : 
'change_settings', :class => 'two_columns' %>
      <% end %>
  <%
  #MES- If the user hasn't selected a timezone, try to guess the 
timezone for the
  #    user, and select it in the select element.
  if 'Unknown' == @user.tz.identifier -%>
  <script>
  set_select('user_time_zone', get_tz_name());
  </script>
  <%
  end -%>
    </table>
  </div>


  Doing the GeoIP stuff would probably yield more precise matches, but I 
figure if the match seems to show the right time for DST and non-DST, 
most users will probably be pretty satisfied.  In my app, I'm usually 
showing dates near the current date, so I don't care so much if the 
timezones diverge in the more distant past or more distant future.  For 
apps that have to show larger ranges of time, my solution may well be 
inadequate, and GeoIP might be more worth the trouble.

  Thanks!



More information about the TZInfo-users mailing list