New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Supporting SystemV time zones #18

Closed
nasa42 opened this Issue Jan 15, 2019 · 4 comments

Comments

Projects
None yet
2 participants
@nasa42
Copy link

nasa42 commented Jan 15, 2019

I noticed that systemv time-zones are not included. We need to support some machines that still use these deprecated time-zones and I was wondering what's the rationale behind not including them and if it would be possible to add support for them in tzinfo-data.

@philr

This comment has been minimized.

Copy link
Member

philr commented Jan 16, 2019

The SystemV zones are not included in the official Time Zone Database distribution. The Zone directives that would define these zones in the systemv file you link to are commented out. This means that they are ignored by both the Time Zone Database zic tool and the tzinfo-data build_tz_modules Rake task.

The policy I've been applying and intend to continue with is to have tzinfo-data bundle the Time Zone Database (in Ruby-form) exactly as it is distributed. I'm leaving all decisions about what does or does not constitute a valid time zone to the Time Zone Database maintainers.

If you want to rebuild tzinfo-data and add the SystemV zones yourself, you can do the following:

  1. Checkout the tzinfo-data git repository and change to the tzinfo-data directory.
  2. Run bundle exec rake tzdb:extract:data to download and extract the tzdata tarball.
  3. Remove the ## prefix from all lines starting ## Zone in the tzdb/$version/data/systemv file (replace $version with the current version being built, as specified in lib/tzinfo/data/version.rb).
  4. Run bundle exec rake build_tz_modules to rebuild the time zone modules.
  5. Optionally run bundle exec rake test to compare the built modules with the result of running zdump on the equivalent zoneinfo files.

It should also be noted that the SystemV zones are not very helpful. The time zones that attempt to apply daylight savings time, such as SystemV/EST5EDT, are not aware of changes made to DST rules in the US after 1976. Other zones, such as EST5, don't apply DST rules at all.

@nasa42

This comment has been minimized.

Copy link
Author

nasa42 commented Jan 20, 2019

Is there any authoritative source of mapping between SystemV time zones and modern time zones? I understand that a correct mapping is unlikely because of DST issues mentioned above, but if I can find any reference to what regions they represented, I can map them to the modern time zone of their region.

@philr

This comment has been minimized.

Copy link
Member

philr commented Jan 20, 2019

If you're aiming for compatibility with another system, it'd probably be best to check what that system is doing (e.g. by checking what transitions are returned by zdump).

The SystemV time zones represent the North American Atlantic, Eastern, Central, Mountain, Pacific, Yukon and Hawaii Time zones. All have versions for areas that observe daylight-savings (e.g. SystemV/EST5EDT) and versions for areas that use standard time all year round (e.g. SystemV/EST5), except Hawaii Time where daylight savings time is not used. Yukon Time is now effectively Alaska Time - Yukon in Canada switched to Pacific Time in 1967.

The Time Zone Database briefly had the SystemV zones linked to other modern time zones. I don't think this mapping was ever released. Note that the SystemV/EST5 link is no longer valid because America/Indianapolis has now itself been made a link to America/Indiana/Indianapolis and only one level of linking is allowed.

The Debian tzdata package includes the SystemV zones as links with a similar mapping (mapping SystemV/EST5 to America/Panama instead of America/Indianapolis).

@nasa42

This comment has been minimized.

Copy link
Author

nasa42 commented Jan 21, 2019

Thank you so much! This is very helpful! We'll use the Debian mappings to support these systems.

If you're aiming for compatibility with another system, it'd probably be best to check what that system is doing (e.g. by checking what transitions are returned by zdump).

Unfortunately, we do not have control over these remote systems. They just report to us with their system time zone.

@nasa42 nasa42 closed this Jan 21, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment