In the UK we have just flipped out of daylight saving.
Time input is subtracting 1 hour from that selected when OK’ed to display start/finish time on widget display
I’m using android. I’m using the latest version of the App (just downloaded).
Any ideas? Do you need any more info from me?
It’s the time input widget labelled Lounge On/Off time top right of the second screen shot. I enter 7 & 8 and get displayed 6 & 7.
The time Input Widget uses “local time”… but I believe that is determined by the sever not the phone?? So I suspect that you need the RTC Widget set to the proper (or adjusted) timezone in order to kickstart the App into the correct setting from the server.
I have the same problem, but I have RTC widget synced with Time input widget in my project. Actions are getting triggered on time, but app calculates and shows one hour less than I have initially chosen. I can also see that in both Time input and RTC widgets my timezone changed from previous GMT+2 to GMT+1. My android app is up to date, ver 2.16.2.
I ran a test overnight to find out how daylight saving changes are handled. This was with the Android 2.16.2 app, using RTC and TimeInput widgets and with the Blynk Arduino library 0.4.10 on the device.
My RTC was initially set to timezone “(GMT+01:00) GB”, which changed to “(GMT+00:00) GB” at 2am, as expected. This meant that getting the clock time using TimeLib repeated the hh:mm:ss from the previous hour.
The timezone setting in the TimeInput widget also changed appropriately. I checked the offset for timezones GB, CET, GMT, UTC. Before they showed offsets of +1, +2, +0, +0; after the clocks changed they showed +0, +1, +0, +0 respectively, as they should. The hh:mm values returned by the widget did not change - in other words, it is up to the device to apply any timezone adjustment.
I do have one question, though.
** Is it possible for the device to read the current timezone set in the RTC widget? **
Thanks, it is probably app’s bug. We’ll check.
@Gunner. I agree the time zone RTC widget time zone should reflect proper/adjusted setting. I concur with @zodiac and @questor that this was done automatically when the clocks went back - so it is all correct.
This still leaves the issue I have shown above. This project has running OK with the time input widget last winter and changed OK for BST. So agree with @BlynkAndroidDev that it appears to be an app issue that must have crept in over the last few months perhaps?
@BlynkAndroidDev please keep us updated as to the fix. As you can imagine if this is a bug it will affect quite a few of us and is a bit of a pain at the moment.
Thanks for your help. The community is wonderful.
After testing I can now concur that whilst the display in the app looks wrong (i.e. an hour less than what we set it at in the dialogue) the actual time communicated to the devise is actually correct i.e. what we set the time to in the dialogue.
So it appears to be a cosmetic display issue on the input the widget - albeit confusing 
OK. So it is all OK now today. Maybe it is just a 24 hr transitional problem you should look at?
Sounds like the RTC / Server didn’t transition from Daylight Confusion Time before your scheduled timer routine… that’s something like the excuse I always used when I arrived an hour late to work… 
Yes, I can also confirm that this bug has gone.
Heh, just started to test it and could not reproduce. Yep, it seems this is daylight gap issue. Could you add here your timezone selection, so I could check why it is still in a daylight switch, when it should not be.
Hello. My time zone is GMT London. I am + 0 hrs now but changed from + 1:00 hr on Sunday morning.
One of those periodic time related obscure bugs which is why I did not see it last winter.
