posted 16 years ago
I have a similar problem. I have a mySQL database on my web server which is somewhere in the USA. In this database I record the dates and times of certain events, such as when people log in, or download certain files. At a later date I want to display these dates and times to a user using a web browser, who will be in UK or possibly anywhere else in the world.
It seems to me that the timezone of the _server_ should not be used - this simply complicates things, such as what if my web site is relocated to a server in a different timezone etc. So all dates and times should be stored in the database as UTC (or Unix timestamps).
It also seems to me that it's a big waste of effort to convert the times and dates from the database to local time on the server, since this means (a) I have to know which timezone the user is in, and (b) the server has to have complete knowledge of how to convert any time and date from UTC to any timezone in the world. It is surely better to transmit the UTC value to the client, and to have the client, which should know where it is, and which timezone applies, and what the rules are, convert to local time.
I will also sometimes need to convert local time and dates entered by the user into UTC so they can be netered into the database - logically this should also happen on the client.
Complications, which don't often appear in articles on this topic, include:
- the localisation of the time may alter the date (including the year), i.e. 1-Jan-2008 02:00:00 UTC is 31-Dec-2007 21:00:00 EST
- the localisation needs to know about leap years, including the special handling of century years (i.e. 1800, 1900 and 2100 are not leap years; 2000 is). This is because localising a time on 28-Feb may move the date to 29-Feb or 1-Mar (or vice versa).
- I don't want just to display the time _now_ in local time; I want to be able to display historical and future times and dates correctly localised. This means that the code has to know if and when DST came into force and ceased in each historical and future year, as well as any changes in the rules about when DST starts and stops.
Does anyone have a good solution to this problem?
I'm not quite sure what the best solution is for users who have scripts disabled.
Thanks - Rowan