If i declare the London timezone last all, both displays show london time, if i declare NY timezone last, both displays show NY time.
It looks like the nodemcuv2 can only deal in one time zone at a time? Is there a why i can change the time zone as writing it to the display. I want to try to get away from just using static +5 hours as this will not take into account daylight saving.
It may help to note that keeping time and displaying time are different things.
That said, the ESP firmware (ESPHome, Arduino, etc) expect to be keeping time to only one timezone. (after all, the machine barely has an internal clock at all, let alone two)
But thankfully, using components like ‘text_sensor’, you can display the time in any zone you wish.
So perhaps keep time in UTC, and display it as many ways as you want, using multiple ‘text_sensor’ components. Examples abound for displaying time/uptime using them.
What Nick said. You are going to be writing plenty of lambda if you are doing display anyhow, so you could use lambda in a sensor to retrieve the +/- of the time zones you want to display, the simply apply the difference from UTC when you print to the display.
Also been looking at time libraries from platformio as per the documentation. I have found a library called " ropg/ezTime" what looks perfect, but when trying to build i get the following error:
/data/travel-clock/.piolibdeps/travel-clock/ezTime/src/ezTime.cpp:10:12: fatal error: EEPROM.h: No such file or directory
****************************************************************
* Looking for EEPROM.h dependency? Check our library registry!
*
* CLI > platformio lib search "header:EEPROM.h"
* Web > https://registry.platformio.org/search?q=header:EEPROM.h
*
****************************************************************
10 | #include <EEPROM.h>
| ^~~~~~~~~~
compilation terminated.
Compiling /data/travel-clock/.pioenvs/travel-clock/src/esphome/components/api/proto.cpp.o
*** [/data/travel-clock/.pioenvs/travel-clock/lib2c6/ezTime/ezTime.cpp.o] Error 1
Compiling /data/travel-clock/.pioenvs/travel-clock/src/esphome/components/api/subscribe_state.cpp.o
The issue with these timezones is that they don’t have DST dates at the same time.
So not only will you need to calculate backwards to NY time, but also keep track of DST.
I haven’t thought this through but perhaps get the time from an API?
You need to do a bit of work because of how ESPHome implements it.strftime() - but below works and will print GMT + 0.5h on the top left of my display.
// string to hold formatted time
char displaytz1[6];
// time zone offset in hours to calculate plus or minus UCT
int offset = .5;
// calculate timestamp as UTC + offset in seconds
std::time_t tz1time = id(my_time).now().timestamp+(60*60*offset);
// convert timestamp back into tm time structure
std::tm *tz1time_astm = localtime(&tz1time);
// convert to string for printing (this is because ESPhome it.strftime for some reason doesn't like tm
strftime(displaytz1, 6, "%H:%M", tz1time_astm);
// print formatted time string
it.printf(5, 10, id(calibri_25), TextAlign::TOP_LEFT, "%s", displaytz1);
Generally speaking timezones is not something you want to calculate yourself.
The code you posted will suffer from the issue I posted (I understand your code is just an example).
27th of march all clocks shifted to summer time in UK. US did it two weeks prior. And the same at the autumn where UK October 30, but November 6 in US goes to winter time.
Yep. You notice I have avoided the issue of timezones and DST completely - and just answered the question about calculating offsets
That said, you could hard code your DST rules and offsets and use those rules as input into the calculation, avoiding extra libraries for instance. The library Nick linked looked pretty good though.
Thanks every one for your efforts here. I have a working solution that i am happy with.
I have gone for Daryl’s code that allows me to change the time with an offset. The issue with that is trying to track DST across multiple time zones. So I have used an API with timezone.io which can be configured to just return an offset per a location. the http request happens once a day at 1 am,
Isn’t it 2 am that the DST happens?
So if you calibrate at 1 am then it will be incorrect by the time you get out of bed.
I would recommend 3 am just to be on the safe side
I know that this is an old post, but I need to create a clock similar to yours for a few time zones.
I thought that this would be simple, but ran into the same problems you had.
Because I live in a state that does not change time I have had a great problem trying to figure out the yaml.
Would you mind sharing your complete yaml for this.
Thanks
