Last weekend (at least in CET-timezone) there was the timeshift from daylight saving time (DST) to normal time.

I thought I had captured all negative effects of "my" application after last years timeshift but as I had to notice I had not. This brought me up to the question: How to test timeshifts, especially the critical "negative" one from DST to normal?

I know there are workarounds this problems by setting the severs to a non-timeshift-zone (like UCT) but assuming your server is set to CET (or any other timezone with timeshifts) how could this be tested? What has to be thought about? Is it enough to manually set the clock of the server? What about client software?

I'm almost sure there are more points you should be aware of but these are the ones that came into my mind.

2 Answers 2


It depends on your system, but usually manually moving the clock, or moving your NTP server's clock, is as close as it gets to reality.

If applicable consider also testing interfaces to other systems where the clock might move a little after or before yours.


DST is my pet peeve. Our application provides services for travelers moving between timezones. Because different countries have different rules, starting and ending DST on different dates (so timezone difference is not always the same). It is really a huge problem, causing constant changes, costing billions of dollars to manage and fix constantly, for no discernible benefit at all. For instance, why USA and Europe cannot switch to DST on same weekend, so the mess (and schedule conflicts) will be limited to one weekend?

If you have to deal with DST changes in just one timezone, your life is easy... :-)

If not, a link to future changes in DST in different timezones may help. Until politicians decide to make some more "improvements".


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.