Hello DL, I know about the possibility of having different TimeZones for different servers (the mysql manual states that it's possible through setting TZ environment variable). But my situation is that I have a shared webhosting in GMT+1 (and mysql TZ is GMT+1), but application needs to have a GMT+2. And now application is almost finished. And this is the only problem (because there are lots and lots of queries allready designed and so on, so I don't want to rebuild almpst whole app). But it looks like I will have to. Or will pay my webhosting provider some extrabucks to have another instance of MySQL server.
But that's very strange, that RDBMS server have no such localization feature. very strange. Can anybody from MySQL AB say when will they implement this? Thanx for all responses. I will notify the list if I'll find out some workarounds with this Friday, March 29, 2002, 1:16:03 PM, you wrote: DN> Hello Maxim, DN> There's a bit of confusion in this discussion: Do you (a) want to have DN> several databases running on the db-server, and all set to different DN> time zones, or (b) want each client to see db-stored times stated in DN> his/her local timezone? DN> (a) AFAIK (and I claim no special expertise here) a single instance of DN> MySQL will only run in a single TZ - I believe that it is possible to DN> run the MySQL in a different TZ to that set at the OpSys/hardware level. DN> That being the case, you likely have to investigate running multiple DN> instances of MySQL to have Byelorussian time, GMT, and NY Time MySQL DN> servers (for example). DN> (b) MySQL is 'server side' coding. Other tools would be required to DN> ascertain client-side information, such as 'user-local time'. Once the DN> local TZ was ascertained, it would be a simple matter to compare that to DN> the server's TZ, and modify all retrieved/entered time values DN> accordingly. DN> I must admit I haven't bothered. For international applications (lazily DN> or sensibly depending...) I simply state that all times are UTC! (with DN> the exception of my family calendar site, where all times (where stated) DN> are 'local' (to the person's/event's location, eg the times a plane DN> flight leaves and arrives)) DN> You will notice that most sites settle for quoting server-local time (no DN> matter how obscure the combination of their location and the user's) and DN> leave the poor user to work out the math. NB contrary to parochial DN> attitudes, most people find converting their local TZ to and from UTC to DN> be easier than working out what the relationship is between two 'local DN> times', eg NZST and PST (mainly because they probably have to compare DN> both TZ values to UTC first and then do the double-math!?) DN> If you are going for (b), what you propose makes good sense. I will be DN> interested to hear how you get on/interested to discuss it further. DN> Regards, DN> =dn >> But how people build web-applications then ? How can you use >> web-hosting in GMT+1 if web-application will be in use in GMT+5 for >> example? >> Have anybody an experience of resolving this problem (without >> embedding this functionality to backend app, because backend app is >> allready contains ~20000 lines of code, and somewhere near to 1000 >> queries). > -- Best regards, Maxim mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
