Opposite of + or - is occurring when selecting time zone
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
built on Thu Jan 05 10:53:36 CST 2017
#2 Updated by Phillip Davis about 2 years ago
"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.
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.
#3 Updated by Phillip Davis about 2 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.
#5 Updated by Renato Botelho about 2 years ago
- Status changed from New to Feedback
- Assignee set to Renato Botelho
- Priority changed from High to Normal
- Target version set to 2.4.0
- % Done changed from 0 to 100
- Affected Version set to All
Changes were added to let user know about how it works, as proposed by Phil.
#9 Updated by Jim Pingle about 2 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).
#10 Updated by Phillip Davis about 2 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.
#13 Updated by Filipe Teixeira 7 months 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
#14 Updated by Jim Pingle 7 months 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
-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
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.