[eclipselink-users] TimeZone issue with the org.eclipselink.persistence.

["Anthony Oganesian" <tony@xxxxxxxxxxxxxxxxxxxxxx>]

Dear all,

I ran into an interesting issue while working with a Time Zone requirement in my application.

Environment:
- 2-tier application (fat client connecting directly to the DB)
- Clients can be started on machines in different Time Zones
- Clients should be working on the same Time Zone as the server. 

To accomplish this goal, first thing I do after the  client connects to the DB is check to make sure that the Client OS Time Zone is the same as DB Server Time Zone. If it's not, I display a warning and set the client TZ  to the DB Server TZ. I do this using:

TimeZone.setDefault(serverTimeZone);

This addresses my requirement except for one serious issue: In queries where I supply Date parameters I get the wrong date in the SQL string sent to the server. For example my Client OS TZ is GMT-8  and DB Server TZ is GMT-6 (2 hour difference). As I supply the parameter to the query, I inspect the Date variable and it prints as "06/08/2009 10:00TZ-06". It's correct because my client is working in the GMT-6 zone However when the query prints in debug mode I see ".... WHERE MY_DATE = {ts '2009-06-08 08:00:00.00'}. Somewhere something still remains that thinks the client is in GMT-8. 

I tracked it down to the org.eclipselink.persistence.internal.helper.Helper class, which maintains a Calendar cache 

protected static Queue<Calendar> calendarCache = initCalendarCache();

Obviously when the application starts and connection to DB initializes (and EL classes initialize) we are in GMT-8, so the cache is populated with Calendar objects created for GMT-8. Subsequent reset of TimeZone.setDefault(serverTimeZone); only affects newly created Calendars. 

Unfortunately, calendarCache is protected and there is no easy way to reset it. For now I dealt with it using reflection to force a reset, but it would be nice to have ability to reinitialize the cache in a proper manner.


Hope this helps someone.

Sincerely,
Tony.