It depends. What are you trying to achieve? We did timeinput in same way as RTC and Timer for consistency. However we are always opened for proposals.
1 Like
@Dmitriy I think beginners expect start and stop times to be what they say i.e. the time something should start and stop relative to their system.
Would it not have been better to adopt the same principle as you use for the original Timer widget where the user timezone adjusts UTC to local clock time? It just saves the backend work that the beginner has to put in to be able to use TimeInput.
Edit: I wrote this post before reading your last post but to me it shows inconsistencies, no?
Hard to say. I would say it depends on point of view. For example. If you use RTC + TimeInput - UTC is better as both work in UTC. If you use only TimeInput - local time probably better however I’m not sure here as do not know how TimeInput is used.
@Costas I would like to get more feedback and after that make decision. Especially we just fixed daylight issue for RTC and TimeInput. So we need to check it first.
The crash of Advanced example is fixed in latest library master
1 Like
I’ve just notice that when setting “RESET” (–:--) to either Start Time or Stop Time is not triggering the:
BLYNK_WRITE(VTimeInput)
Is it would be nice if give some parameter back to this condition, it means there would be 4 conditions:
0 - All time is in reset condition
1 - Start in reset condition
2 - Stop in reset condition
3 - All time is set
Just my thought …
TIA