openevse_esp32_firmware
openevse_esp32_firmware copied to clipboard
Timezone Issues
Selecting Europe/London timezone and NTP results in the correct time being set on the WiFi interface and on the controller :+1:
However, selecting GMT+1 which should be same, results in the correct time being displayed on the WiFi interface, however the controller is 2hrs behind :-1:
Could a solution just be to remove the GMT+X timezones? Since these seem to be a duplicate of the Continent/City timezones.
Thanks to Bill for reporting on the forum:https://community.openenergymonitor.org/t/can-openevse-default-be-set-to-eco-mode/11278/14
I've also noticed that the timezone dropdown menu does not work on iOS, tested on both iOS Chrome and iOS Safari on an ipad mini:

On my iPhone 8 on Chrome it works

tl;dr: I think the "polarity" of the Etc/GMT selections may be reversed.
My timezone (near Seattle, Washington, USA) is nominally
- Winter months: PST (Pacific Standard Time: GMT-8)
- Summer months: PDT (Pacific Daylight Time: GMT-7)
From the provided drop-down, things seem to work correctly if I select:
America/Los Angeles
However, selecting
Etc/GMT-7
is off by 14 hours: instead of subtracting 7 hours from GMT, it adds 7 hours. Selecting
Etc/GMT+7
Works correctly. I think the "polarity" of the Etc/GMT selections may be reversed.
Regarding the Etc time zones they are defined that way: https://data.iana.org/time-zones/tzdb/etcetera. Probably we should just remove them from the GUI (@KipK can you look at this in the v2 UI?), I don't think they are needed in practice. Also see https://stackoverflow.com/questions/53076575/time-zones-etc-gmt-why-it-is-other-way-round
Whilereviewing this, I have however found a few issues and will be submitting a PR shortly
ui2 use same posix_tz_db git source for timezone list. I can filter out the ETC ones yes. Or do we have a better source ?
It nows filter Etc/... tz on the time setting. Pushed in master
Also see https://stackoverflow.com/questions/53076575/time-zones-etc-gmt-why-it-is-other-way-round
Thanks for this!
@KipK the source is 'correct' and to the spec, it is the spec that may not make sense ;-)