SmittyHalibut/EleksTubeHAX

DST - summertime did not start

Frank-Bemelman opened this issue · 5 comments

Frank-Bemelman commented

Hi everybody!

This morning, arriving at my office, noticed that the clock was one hour behind - it had not adjust to summertime.

However, code in main.cpp, around line 311-319 should have picked that up.

The comparison against hour 3 seems a bit odd logic, as summertime starts at 02.00 moving the clock forward,
and when going back to wintertime, it moves back one hour at 03.00

But even ignoring that, it should have adjusted, albeit an hour later.

So the question is, did anybody noticed the same misbehaviour or is it just me.

Cheers,
Frank

aly-fly commented

Hi Frank, mine did adjust just fine.. Woke up on Sunday morning and time was correct. Do you have active and working account at Abstract api?

Frank-Bemelman commented

Ha, thanks! I forgot to mention that it synched properly when turning off and on again.

Apperently it failed getting the GetGeoLocationTimeZoneOffset() result, but it must have failed twice then (sunday 03.00 and this monday 03.00) - with no clue of cource.

Difficult to test again ;-)

Guess I'll have to wait until October to see what happens.

But it is good to know it works.

Not sure if this line of code reflects the best moment:
if (FullHour && (uclock.getHour24() == 3)) { // Daylight savings time changes at 3 in the morning

Here in the Netherlands it changes to summertime at 2:00 and goes back at 3:00 in last sunday october.

aly-fly commented

I didn't check exactly what time should be written there, as I am always asleep at that time :)

Just noted that I have a few devices that use same (free) account and code, and number of requests per second is limited. So adding a few randomly selected seconds after 2 or 3 am must be added at the next revision. This way multiple devices will sucesfully sync even on a free account.

Frank-Bemelman commented

There is this flag FullHour that is only true very shortly. Perhaps copy that into another flag GeoUpdateNeeded = true, and
reset that flag after a succesful retrieval of the GetGeoLocationTimeZoneOffset. And perhaps keep a count of the fails, just to get some insight if and how the service is reliable or what. Just some wild thoughts ;-)

aly-fly commented

This code should fix the issue:
DstNeedsUpdate = (currentDay != yesterday) && (uclock.getHour24() == 3) && (uclock.getMinute() == 0) && (uclock.getSecond() > 5);

This DstNeedsUpdate is True between 3:00:05 and 3:00:59. Has almost one minute of time slot to fetch updates, incl. eventual retries.