I�ve been stumped on this one for quite some time, and I was curious to see if any of you out there would have a clever solution for it.
Basically, what we�ve got is this:
Object1[ ] = an array of objects returned from an external service. Within these objects, we have a �birthDate� field that is of type �Calendar�. If I look closely at these birthdates, I can see the timezone information is essentially blank (or defaulted, however you want to look at it) as just �GMT�.
Object2[ ] = an array to hold a collection of objects similar (but not completely identical) to Object1[ ]. Looking at the Object2 definition, we also have a �birthDate� field here that is of type �Date� (as in java.util.Date).
To get the data from Object1[ ] to Object2[ ], we�re using a dozer mapping.
So you�re asking �what�s the problem?�
Well, truthfully, when this app runs locally (which for us is US Central Standard Time) there is no problem. The mapping occurs just fine. For example:
However, we have users of this application all over the country � that�s where the problem comes in: users of this application west of CST encounter this issue (I�ll use Mountain Standard Time as my example):
So it�s like something (the JVM?) is trying to account for the hour difference between CST (where the code was written & compiled) and MST (where the end product is being used).
Can anyone think of a clever solution to this? I�ve come up with something that halfway works, but it is a very messy hack fix involving adding the TZ offset back into the �mapped� (Object2[ ].Person.birthDate) date. I�d prefer not to use something like that if there is a more appropriate solution.
0
