What tests would you do for Dailight Saving?

Since on the 28th of March the hours will magically change from 3 to 4 I was wondering what tests would you do to cover such scenarios for the applications that you are testing.
Did you have issues because of Dailight Saving? If yes, what where they?

We don’t*/never had any issues. Do bear in mind that for anything date related, most people who write software depend pretty heavily on the kindness of strangers who thought of all the hard stuff already; it’s in the libraries we use.

  • Actually, the Y2K testing period was crazy (yes, I still work for the same company) and we did a lot of leap year and daylight savings tests back then.
1 Like

I’d find out if libraries that already solved this problem are in use at your company.

If it’s a custom build thing in use at your company: YIKES, that’s a huge risk.


I have worked a fair bit in the embedded field and DST problems come up every so often.

One key thing to determine is where the single source of time should live in the system. Mostly I have seen this as being expressed as UTC.

Then when the actual time is needed, as example in the UI, it is converted there.


On a related note, I’ve found a daylight saving bug tonight when uploading the latest Testing Peers podcast episode to Buzzsprout.

Set the schedule time for 11pm tonight and it comes back saying it is scheduled for midnight. Never done this before on previous weeks…


Using some good old test specification techniques like boundary value analysis.
Define datapoints around DST changes for the timezones your app/system uses, including a prediction on how the system should behave. Then time-travel to those datapoints, and then observe actual behaviour

1 Like

Dailight is a rare commodity, and as such the dail stock exchange… maybe I can use it as a day to sell a new NFT? No, seriously, embedded systems.

There was a time when systems that implemented DST would have communication timeouts on the rollover day, and then drop links, fortunately a thing of the past now. Devices that always run UCT and have no network time sync or worse, do have network time sync, are probably the most confusing to model the user interface for. As always testing the user interface, everything else is in UTC, so no worries there.