Andre_br has asked for the wisdom of the Perl Monks concerning the following question:

Hello my loyal code friends,

As I was having many nightmares because of the host I was using here in Brazil, I moved my website to a host in L.A., wich gives me 50 times more disk space and 30 times more traffic for the same fee (something hosts here in Brazil donīt even dream to offer, sadly).

Everything just like a fairy tale untill I asked Mr Server "Hey, man, What time is it?". The problem: Brazil is at GMT -3 and L.A. is in GMT -7, so Iīve got a little problem to solve about this virtual paradox, both in mysql and in Perl, as I have some cron routines that may generate bugs if I call them the wrong hour.

Can you point me something less dirty than doing it by hand, I mean, correcting every localtime(time) call? Also in mysql, I donīt know if I can set a separate timezone for my db.

Thanks a lot

André

Replies are listed 'Best First'.
Re: Timezone antidote
by Tanktalus (Canon) on Aug 31, 2005 at 20:56 UTC

    Standard timezone antidote is to do everything in UTC ;-)

    Of course, it's probably a bit late to do that for you. So the next best thing may be to try to set a TZ environment variable, but if you're sharing a mysql server with others, you probably won't be able to control it. So then you're probably stuck at tuning everything for 4 hours off. If you're looking at all the code anyway, it may pay off to just convert it all to gmtime instead of localtime anyway.

[reply]
Re: Timezone antidote
by cowboy (Friar) on Aug 31, 2005 at 20:59 UTC
    The best way to fix it, is to handle everything in GMT, and take the time to go through and correct it. In perl you can use gmtime(), in mysql you can use UTC_TIMESTAMP(), UTC_TIME(), UTC_DATE().
[reply]
Re: Timezone antidote
by lidden (Curate) on Aug 31, 2005 at 21:09 UTC
    Remember daylight savings change when you fix it. US and Brazil adjust clocks diffrent ways and at diffrent times.
[reply]
Re: Timezone antidote
by fauria (Deacon) on Aug 31, 2005 at 21:29 UTC
    As it has been commented, using UTC is the way of dealing with timezone problems.

    If you cannot use UTC for any reason, or dailight savings differences between summer / winter makes it harder, you can always use NTP (network time protocol) to sync either one of your servers with the other, so for example your LA server works with Brazil local time.
    Update: Of course, you can only change system wide settings such as date in a server of your own, that is, a dedicated server in a hosting plan.

    There is a Net::NTP module which lets you handle ntp responses from your server.
[reply]

      Ewww... that sounds dangerous. Most hosted servers are actually shared boxes, and you could start screwing up other customers' timezone experiences, which, in many ways, would be worse than dealing with it yourself. Of course, if you have sole control over the entire box, go ahead :-)

[reply]
        Hello fellows,

        Sadly iīm in a shared hosting plan and canīt tell Mr Server to adjust his watch. And about the all-GMT solution, Iīm agraid it wonīt fit also, because one of the needs is to print out valid time for events the customers here in Brazil will see the logs, you know? Like, they canīt shop and them see messages and emails saying theyīve bought 4 hours ago in the next second.

        Maybe I have to adjust the time by hand, adding 4 * 3600 seconds to my Perlīs $now variable every time I record a datetime. But I thought there were modules to act as a layer everytime I called localtime() and adjust the timezone, arenīt there?

        UPDATE: As for mysql, how about the .my.cnf file. I donīt have one in my root, but canīt be a way to set up the user-specific timezone, like in this articleīs 4th user-contributed note? http://www.modwest.com/help/kb6-256.html

[reply]

Back to Seekers of Perl Wisdom