Exception from set_curfew API (daylight saving change related?)

[therefromhere]

Just a heads up in case others hit this - I've been getting an exception from the set_curfew API since daylight saving changed for me today (in NZ, so changing out of daylight saving).

I'll look at adding a workaround, but I think this is a once-a-year issue that will go away in a few hours. I think I had a similar issue this time last year.

I think this is because the Sure API is doing some weird adjustment (possibly a bug) to correct for daylight saving changing. Via the website, if I manually set the curfew end time it's subtracting one hour from the requested end time.

e.g. If via the Sure app, I set Unlock time of 7:39, then it succeeds, but shows time on the website (and via the API data) at 6:39.

PUT https://app-api.production.surehub.io/api/device/123/control

request:

{
	"curfew": [
		{
			"enabled": true,
			"lock_time": "18:05",
			"unlock_time": "07:39"
		}
	]
}

200 response: (note unlock_time)

{
	"data": {
		"curfew": [
			{
				"enabled": true,
				"lock_time": "18:05",
				"unlock_time": "06:39"
			}
		],
		"locking": 0,
		"fast_polling": true
	}
}

I think this is a timezone bug from the backend of the Sure app. Maybe something like it's using midnight of current date (rather than current date-time) to figure out if daylight saving is in effect.

On our side, the issue is that we fail this check, because the response unlock_time doesn't match the request time here:

https://github.com/benleb/surepy/blob/980678524efe57ae7935417dd11578b94751afa4/surepy/client.py#L375-L380

Potentially we could change this to a warning.

[therefromhere]

One thing I'm curious of is what the actual curfew will be - e.g. will the GET value change to "unlock_time": "07:39" tomorrow?

[therefromhere]

The issue is no longer happening, I suspect that's because it's now after midnight UTC, so UTC date has changed.

One thing I'm curious of is what the actual curfew will be - e.g. will the GET value change to "unlock_time": "07:39" tomorrow?

For reference, I think the GET value was the one that would be used, I think the bug is that the PUT value was being incorrectly interpreted (i.e. I don't think the GET value would change), so to properly workaround this bug I'd need to adjust the time I'm setting.

[FirstRulez]

Not sure if it's connected but I have noticed that (at least for me here in the UK) whenever our local times change my curfew settings for our cat flap the next day show one hour out, and so every time the clocks change I have to remember to log into the Sure app, and fix the settings.

I assume it's because they store them as UTC and then display them as local time, but then the flap enforces them as local time (which makes completely no sense).

Just in case it is of use/interest.

[therefromhere]

Not sure if it's connected but I have noticed that (at least for me here in the UK) whenever our local times change my curfew settings for our cat flap the next day show one hour out, and so every time the clocks change I have to remember to log into the Sure app, and fix the settings.

I assume it's because they store them as UTC and then display them as local time, but then the flap enforces them as local time (which makes completely no sense).

Just in case it is of use/interest.

Possibly, though worth double checking you have your "Household" timezone to London time and not UTC.

I don't know if the existing time changes for me at DST change, because I have an automated task updating the curfew times to match dawn/dusk every Sunday AM.

FWIW there was a notification in the app "Clock change in your region? You may need to adjust curfew times" which suggests the backend implementation makes no sense like you suggested haha.

[FirstRulez]

Possibly, though worth double checking you have your "Household" timezone to London time and not UTC.

Thanks for the pointer. I have checked and it is set to what I think is the right setting: