Rails: Get timezone offset name

user_5328826 0
Viewed 705

In Ruby or Rails, given a timezone identifier like America/Los_Angeles, I see how I can get the specific timezone offset abbreviation like PDT:

Time.current.in_time_zone('America/Los_Angeles').zone
=> "PDT"

Time.now.in_time_zone("America/Los_Angeles").strftime('%Z')
=> "PDT"

Time.now.in_time_zone("America/Los_Angeles").strftime('%z')
=> "-0700"

And even a friendly name for the timezone itself:

ActiveSupport::TimeZone::MAPPING.key('America/Los_Angeles')
=> "Pacific Time (US & Canada)"

But how can I get a string like Pacific Daylight Time instead of just PDT to represent the full timezone offset name for a specific date?

Input: America/Los_Angeles and a specific date or datetime

Desired Output: Pacific Daylight Time

timezone ruby-on-rails ruby
2 Answers

Short story: ~for some reason,~ (as @bata mentioned in his answer the abbreviations are not unique so this might be a reason for no official abbreviation-human friendly name mapping) The standard seems not to support it. You might need to implement this mapping yourself. But read on if you want to get some pointers why it might not be that easy.

So... this was an interesting rabbit hole to fall into...

Which gems are used and where do they get the info from

ActiveSupport uses tzinfo gem for that which in turn uses tz-info gem. tz-info says it uses one of two data sources:

  • zoneinfo directory in the Unix like system
  • TZInfo::Data

Rails' Gemfile template confirms that TZInfo data is used on window

At first I thought there might be a PR opportunity to contribute to a popular gem. Quick search suggests that there's no mapping of PDT to any "human friendly form".

Looking at unix's zoneinfo database

$ cat /usr/share/zoneinfo/America/Los_Angeles
TZif2H*ˉ#pa&t\؀Ðݩ޾߉iip~KIR^-)4GJQ',3qo_O?/v( fe HG *)
                                                     x                                                   
                                                       q(a'Q                                             
A       0C      ΐ

௠
 #j$5 %J& '*'))6 "S      54+ !"V
eGYe턠g';gfiiHjke lmvG noV) pq6: XX YZ [޵\ ]^d _y`Mޠab-cgwdE G-Gӵ I                                      
                                ros tOt v8vxx͠yz{f|~}H~^s*&                                               
                                                         LMTPDTPSTPWTPPTTZif2^H*ˉ#pa&t\؀Ðݩ޾߉iip~KIR^-)4GJQ',3qo_O?/v( fe HG *)
                    x
                      q(a'Q
A       0C      ΐ

௠
 #j$5 %J& '*'))6 "S      54+ !"V
eGYe턠g';gfiiHjke lmvG noV) pq6: XX YZ [޵\ ]^d _y`Mޠab-cgwdE G-Gӵ I                                      
                                ros tOt v8vxx͠yz{f|~}H~^s*&                                               
                                                         LMTPDTPSTPWTPPT                                 
PST8PDT,M3.2.0,M11.1.0

Looks like a binary file...

$ strings /usr/share/zoneinfo/America/Los_Angeles
TZif2
 v+ !
 2s$
3Gt 4S
5'V 62
mvG n
oV) p
TZif2
 v+
3Gt
5'V
mvG
oV)
PST8PDT,M3.2.0,M11.1.0

Hmm. Whatever each of those means, there seems to be no "human friendly" name for this TZ.

More digging for unix tzinfo format, and there's apparently a zic and zdump tool

$ zdump /usr/share/zoneinfo/America/Los_Angeles
/usr/share/zoneinfo/America/Los_Angeles  Thu Sep 10 03:07:49 2020 PDT

Not very useful...

$ zic /usr/share/zoneinfo/America/Los_Angeles
"/usr/share/zoneinfo/America/Los_Angeles", line 1: line too long

Ugh.

But reading the manpages for one of those tools I've found out that timezoneinfo is an official RFC 8536. I'm not great at reading those, but in the format there's header (with version only) and

  • data block (check it out, apparently it stores all historical changes for the TZ)
  • footer which seems to contain the PDT strings and alike, and nowhere is mentioned a possibility to provide "friendly" name.

If you have hard times reading an RFC, it looks like the tzinfo-data gem tries to reproduce the same data for system that does not include tzinfo databases (i.e. Windows):

https://github.com/tzinfo/tzinfo-data/blob/4ab39f022f5537b97eed133c1169f9ace3a82e2b/lib/tzinfo/data/definitions/PST8PDT.rb

          timezone 'America/Los_Angeles' do |tz|
            tz.offset :o0, -28378, 0, :LMT
            tz.offset :o1, -28800, 0, :PST
            tz.offset :o2, -28800, 3600, :PDT
            tz.offset :o3, -28800, 3600, :PWT
            tz.offset :o4, -28800, 3600, :PPT
            
            tz.transition 1883, 11, :o1, -2717640000, 7227400, 3
            tz.transition 1918, 3, :o2, -1633269600, 29060207, 12
            tz.transition 1918, 10, :o1, -1615129200, 19375151, 8
            tz.transition 1919, 3, :o2, -1601820000, 29064575, 12
            tz.transition 1919, 10, :o1, -1583679600, 19378063, 8
            tz.transition 1942, 2, :o3, -880207200, 29164799, 12
            # ... [cut!]

Here's offset method definition: https://github.com/tzinfo/tzinfo/blob/f361d7d0b859ba5b91d30ffd6b66c3c59f90e969/lib/tzinfo/format2/timezone_definer.rb#L37:L59 (at least I think this is it, you never know until you run the code in ruby)

As you can see, no daylight saving time has :LMT and :PST abbreviations.

And here is the transition method https://github.com/tzinfo/tzinfo/blob/8c549373736a7873e18bb787b818d8786591e5e5/lib/tzinfo/format1/timezone_definer.rb#L30:L61

Feel free to explore more on your own. But it looks like each and every one transition from DST and back is supposed to be present in the tzinfo. And LA seems to have stuff planned until 2060. That's actually interesting if you'll get TZ bugs related to DST if you try to calculate times after 2060?

Last thing: Abbreviations

No idea if this is the case for unix's tzinfo db, but in the gem they are defined locally!

It seems to be the case that :PDT means the same if all definitions (https://github.com/tzinfo/tzinfo-data/search?q=%3APDT&unscoped_q=%3APDT)

But notice that

  • lib/tzinfo/data/definitions/Asia/Manila.rb defines positive offset tz.offset :o3, 28800, 3600, :PDT, but
  • lib/tzinfo/data/definitions/America/Dawson.rb defines negative offset tz.offset :o7, -28800, 3600, :PDT with the same abbreviation.

What does that mean - no idea. But that might be the reason we don't have "global friendly timezone names" anywhere.

There might be errors in the database. The official DB README says:

This database of historical local time information has several goals:

  • Provide a compendium of data about the history of civil time that is useful even if not 100% accurate.

  • Give an idea of the variety of local time rules that have existed in the past and thus may be expected in the future.

  • Test the generality of the local time rule description system.

The information in the time zone data files is by no means authoritative; fixes and enhancements are welcome. Please see the file CONTRIBUTING for details.

user_2997740
user_19664830
Related