The strings you're dealing with are (presumably) UNIX epoch time, the number of seconds elapsed since (usually) 00:00:00 January 1, 1970 UTC. The timezone determines the adjustment from UTC to your local timezone:
#!/usr/bin/perl
for my $tz (qw[GMT America/Chicago Europe/London]) {
local $ENV{TZ} = $tz;
print "$tz: " . localtime '1226667500', "\n";
}
__END__
GMT: Fri Nov 14 12:58:20 2008
America/Chicago: Fri Nov 14 06:58:20 2008
Europe/London: Fri Nov 14 12:58:20 2008
| [reply] [d/l] |
What happened when you tried it? Also note that your database may have conversion routines built in so you can ask it to return the values in the correct zone directly rather than monkeying with them after the fact.
The cake is a lie.
The cake is a lie.
The cake is a lie.
| [reply] [d/l] |
Basically - the "time" (i.e 1226667500) is stored in the DB - at server time (in this case, PST - this will NEVER change, so it needs to be saved like that I guess).
What will never change? The fact that the time is stored at "server time", or that it's stored as "PST"? Typically, when a server uses PST, it uses daylight saving time for more than half a year.
You may not have a choice, but you would make life a lot easier for yourself if you store times at seconds1 after Jan 1, 1970 00:00 GMT2. The number of seconds after that point in time is what localtime assumes as input. It's also generally recommended that (Unix) systems keep time in UTC (GMT). Many time formatting routines (including Perl's localtime) look at the TZ environment variable to determine in which timezone to format the time to.
1Put your fingers in your ears and chant "leap seconds do not exist".
2While GMT existed in 1970, and people still know what you mean with it, it officially ceased to exist See sci.astro FAQ. But when you're timing with a resolution of 1 second, UTC is equivalent to GMT for all practical purposes.
| [reply] |