Re: Dates and different time zones
| From: | Satyam | Date: | Tue, 10 Apr 2007 16:38:24 +0000 |
| Subject: | Re: Dates and different time zones | ||
| References: | 1 2 3 4 5 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-252438@lists.php.net to get a copy of this message | ||
----- Original Message ----- From: "Niklas Karlsson" <niklas.karlssonn@gmail.com>
To: <php-general@lists.php.net>
Sent: Tuesday, April 10, 2007 5:32 PM
Subject: RE: [PHP] Dates and different time zones
Thanks for good answers. Okay, so I should set the default time zone to central GMT time, and then save GMT offset for every user. This sounds realistic, because I don't think that I need to correct the time for users that doesn't login.Well, that was my whole point. If you store the GMT offsets for each user at a certain time in the year, they will turn invalid when they switch from daylight savings to no savings. Not all countries use daylight savings and even those that do don't switch at the same time. Furthermore, northern and southern hemispheres switch in opposite directions, if and when they do. If your users have to log in, that is the perfect time to read their current local time from the browser and keep it just for the session. Don't store it permanently. In PHP dates are stored as seconds from an arbitrary zero set at Jan 1st, 1970, so does MySql with date/time values though it shows them formatted but you can use the UNIX_TIMESTAMP function to get the actual timestamp. JavaScript uses milliseconds from the same base date. The rest is plain arithmetic. Satyam
So, if I now have the GMT offset for every user, how do I display the right date? Can someone please show some phpcode? I would be very grateful if someone could do that.Satyam wrote: Store all of your dates as GMT. Perform all date based calculations around GMT also, and then offset the values for localised display only. This way you only need to store the GMT offsets for each user, i.e. GMT+1 or GMT-8 when it comes to displaying the dates to them. The trick is to use a constant base date for all data, and only being the user timezones into play when needed.Actually, I find that it is better not to bother storing anything for the user at all. At the first chance, get some JavaScript to read the local time of the client machine and send it back to the server, either with the login data, using some AJAX or along with any link the user might click on the welcome screen, for example, the language choice. Then use the offset from his local time to the server time for every time information, substract it from any time information you read from them, add it to anything you send them. This works whether the user is registered or not, whether he/she travels or remains in the same time zone and spares you the trouble of keeping your IP to country to timezone table updated. It assumes that the user updates the time zone on his/her machine and if he doesn't it means she doesn't care, so why should you. (some travellers prefer to keep their portable machines set to their home-base time zone)Of cause the major fault with this is that it can only display the CURRENT time offset. You *ALSO* need the users Daylight Saving Zone as well. This has been giving us great fun since the winter dates and times need a different offset to the summer ones. Something that simplistic browser time offset does not supply. :(The only way to get this working properly at present is to get the user to set their time/daylight settings in their profile, and then you can provide thecorrect offset for all days on a calendar. Remember that for users WITH a daylight saving offset, one day each year has 23 hours and one 25 hours ;)-- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 269.0.0/754 - Release Date: 09/04/2007 22:59