Skip to content
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

GMT offset fix #27

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open

GMT offset fix #27

wants to merge 5 commits into from

Conversation

dhull
Copy link

@dhull dhull commented Nov 21, 2015

Fixed the GMT+H and GMT-H entries in tz_database.hrl, in which the UTC offset was too small by a factor of 60. The tz-erl script had a bug in the offset_minutes function where it treated an offset that was a plain integer as the offset in minutes instead of hours. (Most entries use "HH:MM" or "0".)

Update fmt_shift to handle an argument of 0. This is necessary for tz_shift/3, because tz_shift(_, "UTC") return 0 instead of {+, 0, 0}, and this can cause a problem when using tz_shift/3 to convert to or from UTC.

In tz-erl, made the future date test in zone lines more precise.

In tz-erl, better documented the problem with zone that begin or end using DST in the current year. (But did not solve the problem. This happened in Uruguay in 2015.)

David Hull added 5 commits November 21, 2015 20:30
tz_shift(_, "UTC") returns 0, but fmt_shift/1 previously did not handle
that.  An alternative fix would be for tz_shift(_, "UTC") to return
{'+', 0, 0}.
Previouly when offset_minute's argument was just digits (for example,
"+2" instead of "+2:00"), the argument was incorrectly interpreted as
minutes when it should be as hours.
Worked around 2015 Uraguay problem by allowing database to be generated
for 2016 instead (with "make DATE=2016-01-01").
@dhull
Copy link
Author

dhull commented Nov 21, 2015

This pull request fixes issues #26 and #19.

@jacktang
Copy link

jacktang commented Dec 5, 2015

Well, the database is still not correct, the clock in GMT+X zone faster than GMT+0, so for example GMT+8 should plus 480 minutes not minus.

see commit: dhull@b36ea2c

@choptastic
Copy link
Contributor

@jacktang I do believe you're right, good sir! Good catch!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants