Issues with GMT+-X - minutes instead of hours

[choptastic]

Hi Dmitry,

In https://github.com/dmitryme/erlang_localtime/blob/master/include/tz_database.hrl#L430-L456 there is an issue with the GMT+X or GMT-X timezones where it's only increment single minutes, rather than multiples of 60 minutes.

So for example, GMT+1 is subtracts 1 minute from the time, rather than 60 minutes, as it should.

I suspect it's a bug in the timezone generation script (https://github.com/dmitryme/erlang_localtime/blob/master/db/tz-erl). I haven't taken the time to go through that script to try to identify the source of the error, but my gut tells me @dhull, as the script's author according to the git history might be able to shed some light on this.

I could update the tz_database.hrl file directly, but that seems like the wrong solution. It should be fixed at the script level, I think.

[dhull]

Thank you, you are correct. My Olson database script incorrectly interpreted an offset of the format "HH" as minutes instead of hours. (Most of the offsets are "HH:MM".) I will post a fix shortly.

[choptastic]

Sweet!

Jesse Gumm
Owner, Sigma Star Systems
414.940.4866 || sigma-star.com || @jessegumm
On Nov 21, 2015 3:09 PM, "David Hull" [email protected] wrote:

Thank you, you are correct. My Olson database script incorrectly
interpreted an offset of the format "HH" as minutes instead of hours. (Most
of the offsets are "HH:MM".) I will post a fix shortly.

—
Reply to this email directly or view it on GitHub
#26 (comment)
.

[jacktang]

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

[dhull]

The file tzdata/etcetera file in the Olson database says:

# We use POSIX-style signs in the Zone names and the output abbreviations,
# even though this is the opposite of what many people expect.
# POSIX has positive signs west of Greenwich, but many people expect
# positive signs east of Greenwich.  For example, TZ='Etc/GMT+4' uses
# the abbreviation "GMT+4" and corresponds to 4 hours behind UT
# (i.e. west of Greenwich) even though many people would expect it to
# mean 4 hours ahead of UT (i.e. east of Greenwich).

[choptastic]

Well, isn't that just the most confusing thing ever.

[jacktang]

@dhull "Asia/Shanghai" is "GMT+8" , the offset is 480 min see: https://github.com/dmitryme/erlang_localtime/blob/master/include/tz_database.hrl#L349

And more explain http://wwp.greenwichmeantime.com/time-zone/gmt-plus-8/

[choptastic]

My gut tells me that most people would expect the GMT+X format to be consistent with common usage versus the POSIX-style, but I don't know. Perhaps this is something that should be configurable, otherwise, I will gladly make it an option in qdate that if GMT+-X is the exclusive format of a timezone, that it will interpret as expected.

The POSIX standard for the "GMT+/-X" timezones sounds -- to me -- to be completely broken, but then again, I'm sure there's a reason for it. Then again, just like the "REFERER" header in HTTP, the reason may very well be "I didn't know how to spell 'Referrer'".

[choptastic]

For now, in the branch I'm using with qdate, I've got @jacktang's commit that reverses the + and - with the GMT+5 since I suspect that's what folks expect.

But I'm wondering if maybe it would be worthwhile to add an alternative to the tz_data to have the "Etc/GMT+1" work like we'd expect, and add something like "Posix/GMT+1".

Or, alternatively, since "Etc/GMT+X" is the current posix standard, to add additional non-standard records like "Unposix/GMT+X" which work the reverse of the posix standard, and then re-alias "GMT+X" to the respective "Unposix/GMT+X"

Thoughts?