Time input / time zone problem

Hi all,

After time revert which happened last night, my devices do not want to work with Time input gadget properly. I can see that Time zone within the widget is changed from GMT+2 to GMT+1, and when I try to set start/stop time, after confirming times with OK button, Time input gadget displays one hour less than one that I have just selected. However, timer works if I set start/stop time to desired time + 1 hour. Even if I change timezone to GMT+2, it still displays one hour less than the one I set. I’ve tried to update everything with latest library and delete Time input widget from the project and create new one - problem still exists. Any ideas?

It’s a total mess. On one project I have to select right time, Time input widget shows one hour less, but it works. On second project I have to select right time +1 hour to make it work. Makes no sense at all.

Edit: New trouble - on one device start time stays like desired, stop time asks for +1 hour.

Now I’m totally confused.

I believe all time widgets get their time info from the server, then adjust TZ based on phone… are you running Local or Cloud server?

I also see a problem with the “time input” widget. I have changed the property “allow timzone selektion” +1 hour in all widgets.

It’s cloud, of course. It seems to be the same problem we already had in the past:


The trouble is that Time zone is also changed now, leading to new unpredictable scenarios.

Well, as it did then, it will hopefully sort itself out automatically as all the related reference points align (RTC, Server, Local time, etc.). This “daylight savings” silliness is such a mess every year.

I confirm.
I’m in France and I have to choose GMT+2 instead of GMT+1. :watch:

@Blynk_Coeur Don’t you use Local Server? I admit I mostly use the simple Timer in any time related projects, but I don’t ever recall DST switch-over issues with my Local Server, since it and everything else time related seem to automatically change at the same “time”… I will find out again next week when it happens to me.

1 Like

Choosing GMT+2 is not solving the problem for me. Alexis is obviously using LS.

1 Like

I use local server.
I just solved the problem.
but I don’t know how I solved it.
just set GMT+1 and it works.
it may be due to the transition to winter time

It’s strange, because Belgrade, as well as Paris, is GMT+1. However, Time input widget was always showing GMT+2. Never really bothered me, because everything was working properly.

HI guys its a mess again. I have the same problem as well. Could we have a permanent fix please?

Seems everything is back to normal now.

1 Like

@Dmitriy but has it been fixed? If rights itself the next day and we forget about it for 6 months until the next time it creates havoc

Nope. No time right now. And this is a complex issue that may take a few days. Also, as I know during next year EU countries will stop playing with time:

Under the proposal, member countries are expected to decide by 31 March 2019 whether they wish to retain their current winter time year round – in which case they would change clocks for the last time in October 2019, or their current summer time – in which case the last change would be in March 2019.

Yes and there’s Brexit as well😂. Sounds like the shedule will have it fixed by next time the clocks change

The time input widget doesn’t work properly. Last night we switched to summertime in Europe/Brussels, and now the widget always adds one hour when I press the button.

Please fix the issue. Summertime/wintertime will remain in Europe.

Blynk server: cloud
Androud app, version 2.27.3

Conclusion: not solved

I have considerable experience in dealing with time zone and DST issues.

Only one architectural approach works well.

All time, and date fields use UTC internally, and display local times at the glass. This means that time display widgets either need to know an offset from UTC, or it always calls the OS to convert UTC to local time. Usually the mobile device already has all this and uses the TZ database to know the offset for any given date, and can thus convert form UTC to local time for display and vice versa for time input.

DST rules are political by nature and you can be certain that the rules will change regularly and often with very little warning. Even if they go away in one region, you still have to solve the problem for other regions of the globe, by levering OS level functions under the covers you will leverage the TZ and DST rules that are maintained by Apple and Android, etc.

1 Like