Add tests for zone names / abbreviations

[moment]

Add tests for zone names / abbreviations

[mattjohnsonpint]

Time zone abbreviations can be ambiguous, such as CST referring to "Central Standard Time" (USA), "China Standard Time" or "Cuba Standard Time". EST could be "Eastern Standard Time" (USA), or "Eastern Standard Time" (Australia).

Hawaii is usually HAST, but often HST depending on whether the Hawaiian you ask knows or cares about the Aleutian islands in Alaska.

So if we support abbreviations at all, they should be with a specific output token for .format(), and should be completely ignored when parsing.

We can obtain the correct time zone abbreviation from the tz data. Looking at the sample here, you can see that the abbreviation can be obtained by combining Zone.FORMAT and Rule.LETTER/S columns.

The list here has most of the common abbreviations, but I'm not sure if they align perfectly with the TZDB.

[mattjohnsonpint]

Digging deeper, I see we are doing this already with both .zoneName() and .zoneAbbr(). Why two functions for the same thing?

[mattjohnsonpint]

And from How to read the tz database:

And two last things about the FORMAT column:

• The tz database gives abbreviations for time zones names in popular usage, which is not necessarily “correct” by law. For example, the last line in Zone Pacific/Honolulu (shown below) gives “HST” for “Hawaii standard time” even though the legal name for that time zone is “Hawaii-Aleutian standard time.” This author has read that there are also some places in Australia where popular time zone names differ from the legal ones.
• No attempt is made to localize the abbreviations. They are intended to be the values returned through the "%Z" format specifier to C’s strftime function in the “C” locale.

[timrwood]

@mj1856, we have zoneAbbr and zoneName for the output for z and zz respectively. As zoneName is usually localized, it is not added in the moment-timezone core, but I wanted to build a hook for it in case it was added later or in case someone wanted to write a plugin to handle it as well.

For the tests, I think we can just try to match the zdump output. We already have the tokens in the descriptions of the unit tests, we just need to add them to the unit tests themselves.

// note PST and the end of the test description
t.equal(moment("1918-03-31T09:59:59+00:00").tz("America/Los_Angeles").format("HH:mm:ss"), "01:59:59", "1918-03-31T09:59:59+00:00 should be 01:59:59 PST");

[timrwood]

I added tests for the zone abbreviations in #82, so if that gets merged, this can be closed.