I had to undertake some research into this one a little while ago. All of our users are based in Western Australia, whilst the SaaS servers are located in NSW where there is a two hour time difference. To make it even more interesting, WA doesn't have day-light savings, so during summer the time difference is three hours.
We would periodically see JapserSoft report dates being 1 day out, potentially due to the 3 hour time difference in Summer.
What I did find, was that using Class Type of java.sql.Date did a worst job, java.sql.Timestamp did a better job
You'll notice that I also tried trunc'ing the date (and in my case I then had to add 1 day due to time zone challenges).
I ended up using
- In the select statement, don't format the date, just select it (aka inv.schedule_finish)
- Define it as class type java.sql.Timestamp
- For the TextField I then used DateFormat.getDateInstance(DateFormat.SHORT, $P{REPORT_LOCALE}).format($F{SCHEDULE_FINISH})
The last step I think was more for consistant date formatting in different regions, rather than timezone challenge.
Can't quarenttee the above will work for you as you have a larger timezone difference, but just showing what I did.
You may also consider in your SQL doing:
- to_char(inv.schedule_finish, 'YYYY-MM-DD') schedule_finish_format --- use what ever output format, the one used is Australian
- Define it as class type java.sql.String
This may then restrict the date to the database, rather than the JasperSoft server trying to move dates for different timezone users.