* Jochem van Dieten [...] > > The $usertimezone contains an integer between -12 and +12, > > representing the offset in hours of the user timezone compared > > to the server timezone. A user in the same timezone as the > > server would have $usertimezone=0. > > Some locations have timezone offsets that are not full hours, and > with the addition of DST can be more as 12 hours.
Right... DST = daylight saving time I tried to keep it simple to explain the basics. :) The principle would be the same, but you would use minutes instead of hours, ranging from about -(12*60) to 13*60. A TINYINT would be too small to store it, a SMALLINT would be sufficient. You could also store the number of halfhours. DATE_ADD(datecol,INTERVAL $usertimezone MINUTE) > > If the server(s) also can exist in different timezones, you > > would need an additional $servertimezone integer, and you should > > use GMT as the zero point for both the server and the user timezone > > settings. > > Not GMT, but UTC. Yes, you are right... I meant Coordinated Universal Time. It's basically the same as GMT, except without DST. > > As an alternative you could set all your servers to use GMT > > time, regardless of the geographical placement of the server. > > That way you would only need an $usertimezone offset. > > The proper way to program this would require MySQL to support the > AT TIME ZONE construct, but I haven't found it on the MySQL > roadmap yet. Woudn't the "proper way" be the way that leads to a result you can live with? Of course support in the server would have been better, but why can you not use a mechanism as described above? -- Roger -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
