To enable multiple time zone support, the time zone ID must be specified for each user in the user preferences.
Only DateTimes are processed and displayed in the user's preferred time zone. Date only and Time only fields are not affected and for these fields it is the responsibility of the business logic to ensure that the time zone is not relevant. If the time zone is relevant then a DateTime field should be used. An example of a date where the time zone is not relevant is someone's date of birth; it doesn't vary no matter what time zone that person was born. An example of a date where the time zone is relevant is the current date; this will be different for two user's working either side of the international date line, in this case a DateTime must be used.
The server's time zone is basically the underlying operating system's configured time zone, however the server stores date/times in a time zone independent manner, i.e the number of milliseconds since 1/1/1970 00:00 GMT (also known as the epoch). It is the responsibility of the web tier to convert all DateTimes passed to it from the server into the user's preferred time zone and also to convert all DateTimes to be passed back to the server into milliseconds since the epoch.
The preferred time zone for each user is configured based on the time zone ID specified in the user preferences for the particular user. The time zone ID must conform to one of the time zones returned from the Java method java.util.TimeZone.getAvailableIDs().
Some of the Java supported time zones returned by java.util.TimeZone.getAvailableIDs() method are as listed below:
For information on server time zone configuration consult the Time Zone Configuration chapter in the Cúram Deployment Guide for the appropriate application server.