pfSense

Oh and Yes, the time is also incorrect not just the + and the -

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.

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.

Suggested enhancement to UI:
https://github.com/pfsense/pfsense/pull/3354

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)

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.

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.

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).

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.

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

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.