views:

55

answers:

1

So, I have an XML file I am using with dbUnit as a data source, and it has some dates in it. The date in the file is like so: "2010-02-04", but once it gets loaded and I access it to print or compare in tests, it thinks the date is "2010-02-03 23:00".

I'm guessing this has to do with EDT/EST, but I'm not sure how I can force dbUnit (or possibly hibernate?) to use the correct timezone.

Does anyone have any experience with dbUnit and dates?

Thanks, Peter

EDIT
Okay, I'm pretty sure, for some reason, it's reading the date in as EDT, which is correct, then storing it as EST, which is not technically correct (we are EDT here), but is correct per my computer which says it's EST. This conversion is causing the date to "lose" an hour. Not sure why Java thinks we are EST (Windows XP knows we're not), and am doubly unsure why dbUnit thinks the date should be EDT, since it, like Java, should probably be reading the incorrect timezone as EST. This is pretty confusing.

EDIT I took the Hibernate XML out because that's not the problem. After more poking around, here is what is happening: 1. dbUnit reads the date as a String from the source XML and converts it to a java.sql.Date. By nature, these do not store hours/minutes/seconds, but when you look at the millis, it's clearly adjusted by 4 hours worth in order to show that, though it's midnight here in EDT, it's 4am in UTC. Also, this is backed by a Calendar, which has a timezone that is labeled "America/New York" or something equivalent. I can't exactly remember. 2. Whenever I print this date, my system, which thinks it's EST reconverts 4am UTC to 11pm the previous day, which would be correct, except we're not in EST. 3. Whenever I create a date myself for testing as the example, since my JVM believe we're in EST, it adds five hours worth of millis to make the difference between it and UTC. Clearly, these are different 'dates', and it fails.

So, the real question is, twofold, I guess: 1. Why does my console think it's EST? My Windows XP settings are correct as far as I know. I understand there used to be a problem in Java 1.4 that got the wrong TZ, but I think this has been since fixed and I am running (supposedly) 1.6. 2. Why does dbUnit, which is in the same JVM using the proper fancy TZ.

I suppose I could stop using dates all together, but I don't necessarily have that luxury.

A: 

How are you executing your tests? Try adding the following VM argument to the command line (or however you're executing your tests):

-Duser.timezone=EDT
Andy Mc
I have a feeling that would be a temporarily valid brute force solution, but it doesn't really work across our project. I can't remind everyone who might ever run these tests that they should hard-code their timezone. Plus, it might fail when we drop back into EST.
Risser