Automatic scheduler. ESP-01 with 4 Time Input Widgets

Is it just “UP TO YOU” or the same for all 4 options?

yes same all. picture GMT +3

Can you confirm you used the QR code and didn’t modify the sketch other than entering “credentials”.

Are you using local or cloud server? Could be an issue with a local server and an “incorrect” TZ.

Maybe also try changing the TZ of your phone to +3 but I’m running out of ideas.

yes i use qr code and edit token,ssid,password, only and use default server blynk.com. Thank you for helping

@pasagame I think there is a TZ bug in 2.15.2. I am on 2.15.0. See [Solved] Time input widget time setting offset by +8 hours

Copying to @BlynkAndroidDev

i use on other phone it work but on my phone not work :expressionless:

What app version do you have on the working phone?

blynk 2.10.1 on iphone

now my android is work i downgrade to use blynk 2.15.1

1 Like

It’s correct. TimeInput sends start/stop in UTC, also it passes TimeZone value and TZ_Offset value in seconds.

Only if you changed it in 2.15.2.

This is the thread where it was agreed it would be UTC plus TZ adjustment [SOLVED] Time Input not trigger

TZ adjustment is also sent, it was done in such way from the beginning. That thread should be viewed as plans.

You could check this build for your issue:

But this project was working for all timezones without any time zone coding until 2.15.2 was released.

Checked, bug still exists.

Maybe I do not understand where the problem lies. Is app sending correct UTC data in start/stop and timezone offset as additional parameter or not?

Yes it’s sending UTC and it was agreed and implemented that it wouldn’t send UTC. Up until 2.15.1 you were sending start and stop times as local time (UTC + timezone adjustment).

Or more precisely, if timezone sending is selected for time input widget, the start and stop times were automatically adjusted to local time until 2.15.2 was released.

OK, got it. Yep, my fault, I forgot about this logic in Time Input.

1 Like

Build is updated by the same link.

1 Like

I can confirm the latest logging build fixes the bug, thanks @BlynkAndroidDev

1 Like