I tried the Blynk exmaple “AdvancedTimeInput” on iOS with my local blynk server. I was surprised with the below output i.e. the Start and Stop time I selected from the Blynk App was Start Time: 05:04:07, Stop Time: 19:00:00, however what was displayed as result below was the GMT+0 time — I was expecting the call to getStartHour() etc would provide the correctly GMT+11 (Australian/Melbourne) time – is this a Blynk App error or expected behaviour ?
[5411] Ready (ping: 0ms).
Start: 18:4:7
Stop: 8:0:0
Time zone: Australia/Melbourne
Time zone offset: 39600
Day 1 is selected
Day 2 is selected
Day 3 is selected
Day 4 is selected
@mars at least you have the correct time zone offset. Another Blynker with iOS just gets a figure of 2 the power 32.
I notice the sketch states that time zone offset is added to the Start and Stop times but that doesn’t look to be the case from your data. We use some more detailed sketches that are on this site rather than the GitHub ones for Time Input.
I’ll try running the GitHub version through my ESP to see what it shows.
Must be an iOS issue as the GitHub Advanced Time Input gives the correct data for Android as:
Start: 5:50:0
Stop: 6:0:0
Time zone: Asia/Nicosia
Time zone offset: 7200
Day 1 is selected
Day 2 is selected
Day 3 is selected
Day 4 is selected
Day 5 is selected
Day 6 is selected
Day 7 is selected
have you tried the default blynk server? I wonder if this has something in common with server time?
I’m asking, because even changing the TimeZone in APP DOES NOT changes results of called hour() and minutes(). I can change the time zone in app to whatever i want, and the results of hour() etc sticks as set in widget. The ONLY place I’m using TZ_offset() is the RTC in “blynked” hardware, where it is added to time received from NTP.
I’m SURE that it is not the case. In my opinion it should be just passed to hardware directly as entered in widget (which is the case in my project and default blynk server)
@mars you can try in web browser: http://blynk-cloud.com/xxxxxblynkxxxtokenxxxxxxxx/get/V1
@marvin7 TZ adj IS included in the Start and Stop times but it wasn’t originally designed this way. Originally the widget just provided UTC with no TZ adj. So I believe the iOS version for TimeInput is the old version and therefore working as it was coded.
Until the iOS version is updated @mars just needs to incorporate the TZ adj in their sketch.
But how? Changing TZ in widget does not seem to change results of calling hour() minutes()… Or perhaps I’m wrong? I’m using hours() and minutes() methods to print out TimeWidget settings to serial console only. I’m not using these values for timer operation (instead I use param.asDouble() , you already know that) so it may be, I just missed that!
Perhaps I should rephrase that, TZ adj is included in Android version and therefore the times you set will be the trigger times. With Android, adjusting the timezone will not modify the trigger times as the trigger times are the actual times you select.
For iOS the trigger times are simply UTC and currently require a manual adjustment of TZ adj for the correct trigger times.
@Dmitriy just in case this may have escaped tour view as I know there is a lot of messages on this foumn I wanted to bring to your attention this issue of iOS and Android reporting different values back through Blynk Server (at least from my local server from my testing). I have validated this on my end and sounds like others seeing it as well. It kind of important given it is effected by the Phone OS client being used - Is this logged as a bugged to be addressed in upcoming iOS fix ?
hi @eugene in case you were not aware and given you are working on IOS (which is in much need of some work I feel to cathcup to Android) - there is the above issue that has been reproduced that requires a fix to align with Android.
the correct timezone offset is a good thing !
Thank You for info, though I’m using Android only…
I wanted to bring to your attention this issue of iOS and Android reporting different values back through Blynk Server (at least from my local server from my testing). I have validated this on my end and sounds like others seeing it as well. It kind of important given it is effected by the Phone OS client being used - Is this logged as a bugged to be addressed in upcoming iOS fix ?