Regarding the design of ActiveSupport::TimeZone

195 views
Skip to first unread message

Matt Johnson

unread,
Aug 21, 2013, 7:59:02 PM8/21/13
to rubyonra...@googlegroups.com
Hello,  I am relatively new to RoR, but vastly experienced with time zones and date/time issues on other multiple other platforms.

I answer quite a few questions on StackOverflow in this area, and often questions about ActiveSupport::TimeZone come up.  I'm hoping that someone from this forum can provide the background behind this implementation, such that I am better informed to address these questions.

My understanding is that the Ruby TZInfo gem is the base implementation of the IANA/Olson time zone database, but Rails ships with ActiveSupport::TimeZone which is based on this, with some changes.  It's the changes that I'm unsure about.


> The TimeZone class serves as a wrapper around TZInfo::Timezone instances.

This is the basis for my earlier statements.  But, WHY was it created?  Why not just use the TZInfo gem?

 It allows us to do the following:
>    Limit the set of zones provided by TZInfo to a meaningful subset of 146 zones.

Ok - but who determined which of the 578 zones are "meaningful"?  By what criteria?  And by what review process do newly established zones get determined if they make the cut or not? Is there a recommended strategy for dealing with zones that were omitted?
Also, why limit it to begin with?  The size of the database shouldn't be an issue - since this is all server-side code.  I could see perhaps providing a method to retrieve those that are "meaningful" from the larger data set, but it doesn't make sense to me that they are omitted.


Retrieve and display zones with a friendlier name (e.g., “Eastern Time (US & Canada)” instead of “America/New_York”).

Again, who decides what "friendlier" means?  I sure hope the original names are not lost - since those are keys used for interoperability with other systems that also implement the TZDB.  Are they still available on the TimeZone object?  What about non-English speakers, are these names localized for them?  Some of the names are quite reminiscent of the Display Names of the proprietary Microsoft Windows time zones. Did that have an influence on their creation?

I see that the MAPPING constant is available in the documentation.  That is good.  I haven't fully digested it though - is it a one-to-one mapping?  Does it handle TZDB link alias, such as Asia/Calcutta => Asia/Kolkata or US/Eastern => America/New_York ?

Thank you in advance for any and all information that you can provide.

-Matt Johnson

Frederick Cheung

unread,
Aug 23, 2013, 4:43:30 AM8/23/13
to rubyonra...@googlegroups.com


On Thursday, August 22, 2013 12:59:02 AM UTC+1, Matt Johnson wrote:

Ok - but who determined which of the 578 zones are "meaningful"?  By what criteria?  And by what review process do newly established zones get determined if they make the cut or not? Is there a recommended strategy for dealing with zones that were omitted?
Also, why limit it to begin with?  The size of the database shouldn't be an issue - since this is all server-side code.  I could see perhaps providing a method to retrieve those that are "meaningful" from the larger data set, but it doesn't make sense to me that they are omitted.
 

Retrieve and display zones with a friendlier name (e.g., “Eastern Time (US & Canada)” instead of “America/New_York”).


It may not be a size issue server side, but since part of what this does is power the time_zone_options_for_select form helper, there may have been user friendllyness concerns - all other things being equal a drop down with 146 options is friendlier than one with 500 options. People on the east coast (I assume) identifiy with Eastern Time (US & Canada) but someone in Montreal or Miami might not instantly realise that they need to pick America/New_York.

I think this is also partly an accident of history. Early versions of rails didn't wrap the tzinfo gem (in fact they predate the gem) - I assumed some backwards compatiblity concerns came into play when it was refactored to be based on tzinfo
 
Again, who decides what "friendlier" means?  I sure hope the original names are not lost - since those are keys used for interoperability with other systems that also implement the TZDB.  Are they still available on the TimeZone object?  What about non-English speakers, are these names localized for them?  Some of the names are quite reminiscent of the Display Names of the proprietary Microsoft Windows time zones. Did that have an influence on their creation?

You can access the underlying tzinfo object.
 
I see that the MAPPING constant is available in the documentation.  That is good.  I haven't fully digested it though - is it a one-to-one mapping?  Does it handle TZDB link alias, such as Asia/Calcutta => Asia/Kolkata or US/Eastern => America/New_York ?

Don't know. You may also find the rubyonrails-core list helpful or the rails-contrib IRC channel -

Fred 

Reply all
Reply to author
Forward
0 new messages