Hi,
This is a bit verbose - sorry. I''m going to describe a problem and see
if anyone wants to help solve it.
I''ve been pootling around with my time-tracking solution for a few
weeks now and managed to allow myself to get sucked into the hard
problem if timezones this past weekend.
The issue is that timezones are actually political rather than
practical. Someone recently told me that you needed a maximum of 48
timezones to accommodate DST across the globe - not quite true. DST
is observed according to a region''s political preferences and these
preferences change regularly.
And if you want your best shot at handling timezones correctly you need
to consult the Olson timezone database - if you''re on a POSIX system
the chances are you are using this DB right now (/usr/share/zoneinfo).
Currently there is little support for the Olson DB in Ruby (or Rails).
I did manage to find timezone.rb which utilizes the compiled Olson DB
but this has two problems:
1) The Olson DB as used by timezone.rb is not available on all
platforms.
2) For many apps, Olson has *too_much* data (more than 500 entries) to
present to a user in a "choose your timezone" dropdown list. If
you''re
only interested in making sure you handle DST for the political
landscape of ''today'' then you probably don''t care
about the differences
between Starke or Switzerland county in Indiana.
The perl community has solved problem ''1'' rather neatly by
compiling
the Olson DB into a set of perl modules, making the data platform
independent. A ruby port of DateTime and DateTime::TimeZone seems a
good bet.
As for problem ''2'' - I haven''t found evidence that
anyone has solved
this in a way that doesn''t require significant human intervention.
However, "I have a cunning plan". It involves removing duplicates
from
Olson based on country/region, gmt-offset, dst-rule and weighted by
population (population seems a good metric - my TZ is America/Vancouver
and not America/Victoria despite Victoria being the capitol of BC).
Right now I''m automatically removing duplicates without consulting
population data. It yields some ''interesting'' results like
discarding
Australia/Adelaide in favor of Australia/Broken_Hill - something that
wouldn''t happen if it was weighted by population.
So, if anyone already has a solution for this I''d love to hear about it
- although google tells me not to hold my breath.
Alternatively, if anyone is interested in working on a ruby port of
DateTime and DateTime::TimeZone and/or working on something to generate
an intelligent view of "current timezones" taken from Olson then feel
free to get in contact with me.
Thanks,
Trevor