in reply to Timezone antidote

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.

Replies are listed 'Best First'.
Re^2: Timezone antidote
by Tanktalus (Canon) on Aug 31, 2005 at 21:40 UTC

    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 :-)

      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

        GMT is the storage solution, not the output format. Store all the times in UTC/GMT, and when you actually need to print them out, then use TZ-aware tools and use the localtime features. From one of my scripts, I have:
        use POSIX qw(LC_TIME); $ENV{'TZ'} = "GMT-1"; $locale = "gb_UK"; POSIX::setlocale(LC_TIME,$locale); my $todaysdate = POSIX::strftime("%a %b %d %H:%M",localtime());
        For the machines in the UK, that changes between -1 and -0 for summer and not, and the machines in germany, that changes between -2 and -1 for summer and winter, and locale is de_DE. Calling localtime() will then view the time as it should be in your locale.


        the hatter

        Side note - if it's just emails you're worried about, you can start by just sending the emails with any timezone - the header should automatically be adjusted by the client. For times inside the email, check out Time::Zone - rather than adding 4*3600, try tz_offset('...') where '...' is the timezone you want your output to be in.

        Perhaps one of the more experienced pmdevils here would know how PM handles the same situation since everyone can specify the timezone they want to see stuff in.