org.embulk.util.timestamp

Class LegacyDateTimeZones

java.lang.Object

org.embulk.util.timestamp.LegacyDateTimeZones

public final class LegacyDateTimeZones
extends Object

This class contains a static method to interpret a timezone string in the historical manner of legacy Embulk.

American timezones

Legacy Embulk's org.embulk.spi.time.TimestampParser starts interpreting a timezone string from Joda-Time's DateTimeFormat like below. It was before straightforward DateTimeZone#forID and DateTimeZone#getAvailableIDs.

 DateTimeFormat.forPattern("z").parseMillis("PDT")

It had been in Embulk since v0.1.0 until v0.8.20. GitHub Issue #860 describes the details.

It unfortunately caused some wrong conversions for some American timezones: "EST", "EDT", "CST", "CDT", "MST", "MDT", "PST", and "PDT". For example, "PDT" should be recognized as "-07:00" because "PDT" was a daylight saving time. But, "PDT" was actually recognized as "-08:00" along with "PST".

It was because "PDT" and "PST" were aliases of "America/Los_Angeles" in Joda-Time, not aliases of a fixed offset. Joda-Time originally intends to recognize both "PDT" and "PST" to be aligned with the date-time with the timezone. For example, "2017-08-20 12:34:56 PST" goes to "2017-08-20 12:34:56 America/Los_Angeles", and this "America/Los_Angeles" is recognized as "-07:00" because the date was in the daylight saving time. Same for "2017-08-20 12:34:56 PDT". This "PDT" is eventually recognized as the same "-07:00" because of the date as well.

However, DateTimeFormat.forPattern("z").parseMillis("PDT") was always converted to "-08:00" because the string, only "PDT", does not have any date information. Legacy Embulk never recognized "PDT" as "-07:00" even for summer as a result.

JFYI, the set of special timezones comes from DateTimeUtils#buildDefaultTimeZoneNames.

"HST" and "ROC"

Embulk replaced Joda-Time into Java Date and Time API when upgraded to Embulk v0.9. It started to use ZoneId.of instead of DateTimeZone.forId at that time.

ZoneId.of(String) does not recognize "HST" nor "ROC" that are recognized by DateTimeZone.forID(String).

Available timezones in Joda-Time are described in Joda-Time - Java date and time API - Time Zones.

See Also:

DateTimeUtils.getDefaultTimeZoneNames()

Method Summary

Modifier and Type	Method and Description
static ZoneId	toZoneId(String zoneName) Converts a timezone string to ZoneId in legacy Embulk's manner.

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Method Detail

toZoneId

public static ZoneId toZoneId(String zoneName)

Converts a timezone string to ZoneId in legacy Embulk's manner.

It recognizes a timezone string in the following priority.

1. "Z" is always recognized as UTC in the highest priority.
2. Some special timezone strings are recognized by ZoneId.of(String, Map) with a predefined alias map like below for legacy historical reasons.
   • "EST" is recognized as "-05:00".
   • "EDT" is recognized as "-05:00", too.
   • "CST" is recognized as "-06:00".
   • "CDT" is recognized as "-06:00", too.
   • "MST" is recognized as "-07:00".
   • "MDT" is recognized as "-07:00", too.
   • "PST" is recognized as "-08:00".
   • "PDT" is recognized as "-08:00", too.
   • "HST" is recognized as "-10:00".
   • "ROC" is recognized as the same as "Asia/Taipei".
3. Otherwise, the given timezone string is recognized as Ruby-compatible zone tab.
4. If none of the above rules does not recognize the given timezone string, it returns null.

Some of its time offset transition (e.g. daylight saving time) can be different from Embulk's actual historical transitions. But, the difference comes from their tz database version difference. The difference should be acceptable as users should expect tz database can be updated anytime.

Parameters:

zoneName - a timezone string

Returns:

a ZoneId converted