Testing correct timezone handling

Question

We are working with large amounts of data, all tagged in UTC (in Java). Between reading this data, storing it in a database and getting it out again, it happened, that some data was off one hour during daylight saving time. As UTC has no concept of daylight saving time this was clearly a bug within the software. Once known, it's easy to fix.

However, it'd be nice to have some unit/integration tests that work regardless of the current time difference - e.g. I'd like to change the local time zone and run some methods over and over again within these different time zones to make sure UTC is handled correctly.

As the tests should run automatically and - preferably - within one Testsuite, I'm wondering how to best test for correct behaviour. It'd be easy to change local settings like time zone upon restarting the JVM, but running this within a test suite is not that easy.

Does anybody know of a test environment, library or pattern supporting this scenario? We're usually working with JUnit, but are open for adding another environment/technique if it helps getting rid of problems like this. I suppose that it's rather an integration- than unit test.

Edit: There are already two very helpful answers, but I guess there must be more techniques out there. Does anybody have authoritative information about when/how often TimeZone.getDefault will be called (see the comments for Jon Skeets answers)?

Note: Even though this question has an accepted answer, I was not completely sure, which answer to accept. Even with this acceptance I'd like to see more ideas and techniques.

Thanks for your input!

Answer 1

Java allows you to set the default timezone (java.util.TimeZone.setDefault). I've written tests before to set the timezone to a variety of different options and check that everything still works. Be careful though - if you're parallelising most of your unit tests, you'll need to make these ones sequential.

I suggest you test in some timezones with daylight saving time applies, and some without. Using an Australian timezone is good as well, as DST applies at the opposite time of the year to the northern hemisphere.

Answer 2

I would recommend you check out JodaTime which provides some sugar to help manage Date / Time / TimeZone type issues more legibly in your code.

We use these throughout test and production since how it boosts the native Java API for Date/Time issues is unparalleled. Using these in tests works fine within JUnit

Answer 3

What is the opinion about connecting to time servers and getting updates ?