Hi Your Mother,

thanks for mentioning the headers. Unfortunately, due to the nature of the application, every user (once logged in) consistently should always work in the time zone and with the locale he has chosen, regardless of the browser he uses and from where he uses it. Thus, the time zone and the locale will be part of the master data of every user's profile.

Thanks again,

Nocturnus

This is the second half of what I suggested. :P Cookieing the user with her preferences. The argument I'm making is that the only sane autodetection is the Accept header and the user should always be able to choose to override it. This doesn't sound at odds with what you're doing at all.

You are right, and at the very moment I'm working on it :-)

Thanks again!

Nocturnus

due to the nature of the application, every user (once logged in) consistently should always work in the time zone [...] he has chosen, regardless of the browser he uses and from where he uses it.

That's quite strange. Maybe the users are trained to work like this, or maybe the users don't travel. I would prefer to see the timezone of the place where I am, not of the place where I have been some days ago. Another option would be that all users (are forced to) agree to use the same time zone, regardless of their location. This seems to be usual for aviation, using UTC instead of local timezones.

Anyway, here is a trick that I used years ago in a CGI-based application, when Perl 5.6, Netscape 4.7x, and Internet Explorer 5.0 were state of the art:

The Date object in Javascript has a getTimezoneOffset() method, since Javascript 1.0. I planned to use that offset to present date and time to the user, while using UTC internally for any date and time. My plan was to detect the offset during login, then use it on the server side to adjust date and time. But then, minutes later, I discovered that the Date object can do better: You can get and set the number of milliseconds since the Unix epoch (1970-01-01 00:00:00 UTC) using getTime() and setTime(), and the Date object automatically converts from and to local time. I didn't have to care about time zones at all, the browser did that for me. I simply passed around timestamps in seconds since the epoch, with some trivial Javascript code to convert from and to milliseconds since the epoch. Some more Javascript code formatted the date to match the application's settings. (The toLocaleString() and toGMTString() method return strings depending on the OS settings and the browser language, so I had to replace them with custom functions.)

It turned out later that, when time was omitted and only date was displayed, some dates magically changed by one day, heavily confusing the user. The problem was that I stored dates as timestamps for the day's local midnight, which is yesterday's 23:00 one timezone to the west. The simple workaround was to store dates as the timestamp for the day's noon. This gave consistent dates even across several timezones.

Implementing an "aviation mode" that uses UTC instead of the local timezone would have been quite easy, just adding an if-then-else to the formatting functions to use the getUTCXxx() methods instead of the local timezone methods of the Date object; and of course require that people stop using Internet Explorer 4.x (which does not support the UTC methods).

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)