Date and time handling in applications serving clients in multiple time-zones?

Question

The internationalization problems associated with string handling can pretty much be solved by following the advice: use Unicode and store everything as UTF-8 in your database, then you'll be able to serve clients using all the world's languages.

But what about the internationalization problems associated with date/time handling?

Questions:

• Are there similar easy-to-follow best practices for solving the internationalization issues surrounding time handling?
• How do you make sure your applications can serve clients operating in different time zones? What issues did you encounter and how did you solve them?

Answer 1

I have following advices,

1. Store all your time in database with one timezone, preferably Zulu (GMT).
2. Assign a timezone to each user at registration. We normally figure this out from the language of the registration page or the code embedded in the promotion link. Sometimes, we have to ask user.
3. Make clients timezone-aware. This means client can't display time from server as is. Must be displayed in local timezone and in local format.
4. Client should make some effort to get timezone info of the system. If not, server can guess from various data. We got good results using language first, then IP address. In any case, client needs to display time with zone info so user knows what's going on when time is wrong.
5. Need special flags for certain time values that's not affected by timezone. We had a mistake that user's birthday changes when they change their locale. Other things belonging to this category including holidays, store hours etc.
6. If you have to sync up clock with server, please don't change system time, just store the delta in your client. We had a security requirement that the clock must be in sync with host. So our client syncs system clock with our server on startup. That's the wrong thing to do. For older systems like Windows 95 with no timezone, we changed their time into GMT. Finally the older clients went away but we are facing a new issue is that we messed up the accurate time from NTP.

Hope some of our mistakes will help you to avoid them.

Answer 2

I'd had some luck with this by using some JavaScript to have the client inform us of their time zone. If I remember it involved calculating the current time on the user's machine in local time and then comparing that against Zulu.

Answer 3

ZZCoder has some good points. Here are some more:

• All datetime values must have an associated timezone. You should define what it means if a datetime doesn't have one (for instance, in some cases, it will mean GMT+0; in others it is because the code is in the middle of figuring it out and assigning one).
• You will probably need to attach events with a datetime to a location. This means that you will have a way of figuring out when a datetime's timezone is allowed to change. This solves the problem of birthdays moving, but it also allows intelligent behaviour when daylight savings starts or ends. However, be careful of unintended relationships: setting up a meeting for several people in different timezones should reference one canonical entry, not copy datetimes and localize them.
• Do not do calculations yourself: always always always ask the library functions to do datetime calculations.