hey,
this is a tricky problem. What you are probably interested in is
guessing someone’s ‘locale’, not their timezone. The reason is that
most locales change timezones once every year; but not all do. Your
servers current timezone might be CST, but chances are that in a few
months it will switch to CDT. Same with most of your clients. Then it
gets even more complicated because when timezones switch is constantly
changing. The USA, for one, is stipulating a change this year. And to
make it even more complicated, you have ‘odd’ cases where places like
Arizona don’t change their timezone at all throughout the year, while
other states like Indiana have 5 different locales (some areas don’t
change timezones, others are in easter, some in central, etc). It is
complicated!!!
So, with that in mind, one solution, that as far as I know works for
almost all cases (see below for disclaimer 
is this:
- have the client, in javascript, compute the UTC offset for two dates,
‘2005-06-30’ and ‘2005-12-30’ (or any date that will always be in one
timezone and another date that will be in the other)
- using the two offsets, search through all possible locales for that
which has the same winter and summer UTC offsets.
For example:
summer_offset == -21600
winter_offset == -20600
matches the America/Los_Angeles locale
summer_offset == -21600
winter_offset == -21600
matches the Pacific/Galapagos locale
summer_offset == 34200
winter_offset == 37800
matches the ‘Australia/Yancowinna’ locale
this works, but isn’t perfect because it is possible to match multiple
locales. But you might be able to use a trimmed down list of locales
that highlight only the major ones. The other catch is that you are
choosing two dates (in our case ‘2005-06-30’ and ‘2005-12-30’) which
you assume will always be in one timezone or the other; but what if
that is not always the case. As far as I know it is currently the
case, but when timezones switch for different locales is always
changing, so this solution might not be future proof.
I have my logic so when a user registers for an account, I figure out
their current timezone. I have two hidden form fields called
‘summer_offset’ and ‘winter_offset’. Then in javascript I do this:
try {
$(‘summer_offset’).value = -1 * (new Date(Date.UTC(2005, 6, 30, 0, 0,
0, 0))).getTimezoneOffset() * 60; // in seconds
$(‘winter_offset’).value = -1 * (new Date(Date.UTC(2005, 12, 30, 0, 0,
0, 0))).getTimezoneOffset() * 60; //in seconds
} catch (e) {}
in my controller, I pass the parameters to this method, which will spit
out a string containing the locale identifier:
trying to automatically determin a users time zone
this is possible, but note that the locale might be off (say the
local is America/Boise, but it chooses America/Denver instead)
if a timezone is not found, will return nil… you can then set the
default timezone to whatever you want: UTC perhaps?
def find_time_zone(winter_offset, summer_offset)
default_tz = nil
return default_tz if winter_offset.blank? || summer_offset.blank?
# look at two dates that will, by and large, reside *between* major
time changes within a zone.
# ie, they won’t fall on a day where the time is actually changing
summer_date = “2005-06-30”.to_time
winter_date = “2005-12-30”.to_time
winter_offset = winter_offset.to_i
summer_offset = summer_offset.to_i
# this comes from the client, where they should have something like
so (for a html client):
# $(‘summer_offset’).value = -1 * (new Date(Date.UTC(2005, 6, 30,
0, 0, 0, 0))).getTimezoneOffset() * 60;
sd_offset, wd_offset = nil
# need to go through each timezone and find a match for the summer
and winter offsets
default_tz = nil
TZInfo::Timezone.all.reverse.each do |tz|
# get the summer date and winter date total utc offset for the
timezone
# This includes the utc offset plus any change with daylight
savings
sd_offset = tz.period_for_local(summer_date,
false).utc_total_offset
wd_offset = tz.period_for_local(winter_date,
false).utc_total_offset
# at first I thought I had to have this if PLUS another one where
the == were mixed like:
# sd_offset == winter_offset && wd_offset == summer_offest. This
check is not needed
# because the summer_date and winter_date are aligned between the
client and the server.
if sd_offset == summer_offset && wd_offset == winter_offset
default_tz = tz
break
end
end
unless sd_offset.blank? || wd_offset.blank?
#THIS is a _tad_ elitest. Ccan the US zones to try and better
match the locale.
#If a timezone matches in the US, use THAT locale…otherwise use
the original one
new_time_zone = TZInfo::Timezone.us_zones.find do |z|
z.period_for_local(summer_date, false).utc_total_offset ==
sd_offset &&
z.period_for_local(winter_date, false).utc_total_offset ==
wd_offset
end
#we can add other ‘cleanup’ loops here if needed…
default_tz = new_time_zone unless new_time_zone.blank?
end
default_tz.blank? ? nil : default_tz.identifier
end
its a heavy approach, but it is the most complete that I could come up
with. Let me know if you think it would work for you.
cheers!
Adam