Adding Timezones to JasperReports Server
Q: How can I add more timezones to the list of available timezones in the JasperReports Server login page or on the report scheduling page?
How does JasperReports Server Pick Up DST Changes?
Typically the JVM detects the time zone from the OS, however there have been times when it does not. To test what Time Zone your JVM is using try the code snippet on this page: http://www.minaret.biz/tips/timezone.html
Automatically using the client's timezone
Q: JasperReports Server lets the user choose the timezone to use. But it would be easier if it just automatically used the browser's timezone. In fact, iReport just uses the machine's local timezone. JasperReports Server should do the same. Why don't you do that?
A: It's complicated.
When a report gets filled you need to use some timezone. iReport uses the timezone reported to it by the JVM. This is clearly the choice that the developer most likely wants. But sometimes it's useful to test the report for a different timezone. Because iReport is a developer-oriented tool, it's easy for the user to simply apply a command line parameters (e.g. -Duser.timezone="Australia/Sydney") to get what he wants for testing. In JasperReports Server we consider it analogous to let the user choose his timezone manually. It's common for an administrator to modify the list of timezones available in that drop down, so you certainly do need to stay with the default list provided out of the box. Some users feel that it would be easier for them if JasperReports Server automatically used the browser's timezone rather than some arbitrary default. Frankly, they're correct. For most end users this would be easier.
There are two main problems to overcome.
- If we take the browser's timezone, this is good for most users. But there are cases where a user needs to specify a different timezone. (When I run a report for Europe, it can be important to use their timezone even if I'm actually use the United States.) If JasperReports Server doesn't provide a dropdown list, then this user has no possible workaround to get what he needs.
An obvious alternative could be to use the browser's timezone by default but still allow the user to override this. Again the problem is a practical one: Java supports 558 time zone (give or take a few depending on the version). We would need to make sure JasperReports Server handles any of these that the client might send.
"But wait," you think. For any given session we can simply ignore Daylight Saving Time and ignore the large number of identically-defined timezones. In this case we can simply pass the GMT offset and allow a dropdown with the 25 or so possibilities of overriding this. The reason this won't work is because the timezone gets used when the user schedules reports. Using GMT-8 would be fine for any reports that I run today. But if I schedule a report to run weekly at 7:00 am, I expect it to run at 7:00 am Pacific; and that won't be GMT-8 when we transition from winter to summer. These complications are the reason that we decided that the best compromise was to include a list of timezones that the user can select from. Again, this list is easily modifiable by the administrator. One could certainly say, "For this given implementation, the end user never has the requirement to manually modify the timezone." In this case you can get what you want, but it would require a customization.
The customization go like this:
- Modify the login page to include this timezone rather than the dropdown list. This should be very easy.
- Update the userTimeZonesList bean in applicationContext.xml to contain any possible timezone used by a client (you can even write a custom TimeZonesList implementation if you want to programmatically build the list of JS timezones). This is required because the scheduler screen uses the user session timezone as default schedule timezone, and if the user timezone is not in the list of JasperReports Server timezones the screen would malfunction.
So the customization is not trivial, but it's not overly difficult either. The key unknown is step one, which is probably easy to solve for a given customer but not easy to solve well for all Jaspersoft customers.