Bug #7089
closed
Opposite of + or - is occurring when selecting time zone
Added by Geoffrey Bricker almost 8 years ago. Updated about 6 years ago.
100%
Description
I select ETC/GMT-5 on the web interface, and typing 'date' in shell shows the opposite, +5. I changed to -4, it went to +4. I changed to +4, it went to -4.
This is on the Netgate SG-1000
2.4.0-BETA (arm)
built on Thu Jan 05 10:53:36 CST 2017
FreeBSD 11.0-RELEASE-p5
Updated by Geoffrey Bricker almost 8 years ago
Oh and Yes, the time is also incorrect not just the + and the -
Updated by Phillip Davis almost 8 years ago
https://en.wikipedia.org/wiki/Tz_database#Area
"The special area of "Etc" is used for some administrative zones, particularly for "Etc/UTC" which represents Coordinated Universal Time. In order to conform with the POSIX style, those zone names beginning with "Etc/GMT" have their sign reversed from the standard ISO 8601 convention. In the "Etc" area, zones west of GMT have a positive sign and those east have a negative sign in their name (e.g "Etc/GMT-14" is 14 hours ahead/east of GMT.)"
Goodness knows why really, but there you have it.
I guess something can be put in the GUI to alert users to this "feature" of timezone specification.
Some more info:
https://github.com/eggert/tz/blob/master/etcetera
https://github.com/eggert/tz/commit/5659c5322976ea171e6a5afe14e9bc8172a51e24
The "feature" happens on 2.3-RELEASE, 2.3.2-RELEASE, 2.3.3-DEVELOPMENT and 2.4.0-BETA. So all current pfSense installs work like this. I guess it has been like ths for a while.
Updated by Phillip Davis almost 8 years ago
Also, 99.9% of users should be selecting a timezone based on a continent/city in their area. This makes summer time changes happen as needed and so on. That all works - I double-checked switching to Sydney, Kathmandu and New York and time happens as expected.
Updated by Phillip Davis almost 8 years ago
Suggested enhancement to UI:
https://github.com/pfsense/pfsense/pull/3354
Updated by Renato Botelho almost 8 years ago
- Target version set to 2.4.0
- % Done changed from 0 to 100
- Affected Version set to All
- Status changed from New to Feedback
- Assignee set to Renato Botelho
- Priority changed from High to Normal
Changes were added to let user know about how it works, as proposed by Phil.
Updated by Geoffrey Bricker almost 8 years ago
Just so I can be clear, you're saying the intended behavior is that - is + and + is minus? Every other device I've ever selected -5 has always ended up being EST (give or take DST)
Updated by Jim Pingle almost 8 years ago
You should not be picking what you think is an offset (but is really a special-use time zone). Pick a geographic zone. Those zones are not what you think they are, thus the confusion.
Updated by Geoffrey Bricker almost 8 years ago
In every other environment I've worked in that I can think of, you can pick the -5 and it's correct. Why is this any different? You're going to have issues with that with a lot of people.
Updated by Jim Pingle almost 8 years ago
pfSense is not other products. And the Etc zones are NOT what you want, likely ever. We have been tempted to remove or hide them in the past. We have changed the language on the option to make that more obvious. If we cosmetically flipped the signs, it would likely lead to even more confusion.
In addition to the source Phil posted above with reasoning, there is also this from the tz database:
# 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 UTC # (i.e. west of Greenwich) even though many people would expect it to # mean 4 hours ahead of UTC (i.e. east of Greenwich).
Updated by Phillip Davis almost 8 years ago
The thing needs to be kept in-line with what the "standard" tz-database distribution is doing. Otherwise, as Jim says, it will get even more confusing as some people know what the tz "standard" did and expect that.
I expect that this behavior will be in any OS that is taking the "standard" tz distribution. So not just FreeBSD/pfSense, but every Unix/Linux out there.
Updated by Jim Pingle almost 8 years ago
- Status changed from Feedback to Resolved
New descriptions are more clear, options are labeled in a way that is hopefully obvious.
Updated by Jim Pingle almost 8 years ago
- Category set to Web Interface
- Target version changed from 2.4.0 to 2.3.3
Updated by Filipe Teixeira about 6 years ago
Although the description tells how it works, the GMTs are wrong.
The correct GMTs are "+" (before GMT) and "-" (after GMT), as demonstrated at https://en.wikipedia.org/wiki/Coordinated_Universal_Time#/media/File:Standard_World_Time_Zones.png
Updated by Jim Pingle about 6 years ago
The description and behavior are correct for POSIX style zones. See note 9 above. The "Etc/GMT+4" zone means 4 hours WEST of GMT, which is 4 hours BEHIND.
So Etc/GMT+4 is GMT -0400, and the output of date shows -04 in this case. The time is correct. Since my normal zone is 4 hours behind GMT this time of year, my clock doesn't change when set to this zone, as expected.
If you select Etc/GMT-4, this is 4 hours EAST of GMT, which is 4 hours AHEAD of GMT. Changing to this zone still works as expected. My clock now shows 8 hours ahead of my actual time with +04 in date output.
Everything is correct and working as intended. If you find the descriptions confusing, do not use the Etc/GMT zones. They should only be used in special cases anyhow. The vast majority of users should be on geographic zones.