Daylight Saving clock change BST GMT for Mobile testing iOS

Hey all,
In late October the clocks will change, due to daylight saving, we will go from BST to GMT.
I test a parking app, and we are trying to ensure the customers who use the app, don’t have problems, or unexpected behaviour due to the time change. Such as their parking sessions moving into scheduled because of the time, or them being logged out for any reason, or being over charged.
Testing is proving a challenge, because we can change the server time to GMT or 1 hour behind, and the phone time, but is it better to change the time to London -1h to test, or change the time zone to somewhere like Reykjavik which is 1 hour behind.
I know it depends on how the app is coded, but that still doesn’t tell me the best way to change an iPhones time to simulate the clock change.

This seems like it might be something that’s useful to do some risk analysis around? For example, is the client time being used for anything meaningful? If just changing the time on my phone means I can trick the server into think I started parking at 3 PM when I really have been parked in 8 AM seems problematic? Or letting me fake the request at 3 PM to make it look like I had paid for parking since 8 AM so I can contest a parking ticket?

If the client time is being used at all, hopefully its only on the display side?

1 Like

I am late to this thread but have to test DST routinely. What I do is turn on airplane mode, set the device time and date to future, run the entire test. Once the test run is complete i return the device to current date/time then I disable airplane mode and send any data/logging to assess the outcome.

1 Like

Hi Linda,

Flight mode does sounds interesting, I don’t think that will work for the app I test as it requires an api response from the server in order to calculate what to show on the next page to complete the journey.

(I have tested changing the timezone, and the device time, but if it calls on the api, that can return the real time.)

However I could try putting breakpoints in a debug proxy software we use to fake a response.

Thanks for your suggestion.