Re: Time::Piece epoch parsing

runrig++ idea looks right. in OP's code, strptime() interprets the input value as a local time. It then subtracts 3 hours to get the output GMT epoch value.

I ran this code myself and in my time zone, I get the following result:

use strict;
use warnings;
use Time::Piece;
my $x = '1415998800';
my $t = Time::Piece->new();
print Time::Piece->VERSION, "\n";
$t = $t->strptime( $x, '%s' );
print "Input $x\n";
print "Output ".$t->epoch(), "\n";
print $t, "\n";
print $t->strftime, "\n";
print "daylight savings flag is:",$t->daylight_savings, "\n";

__END__
1.30
Input 1415998800  <- interpreted as a local time
Output 1416027600 <- 8 hours ahead of input
Fri Nov 14 21:00:00 2014
Fri, 14 Nov 2014 21:00:00 Pacific Standard Time
daylight savings flag is:0
[download]

What I don't understand is why Time::Piece doesn't know that currently Daylight Savings time is in effect? Right now, GMT is only 7 hours ahead of us instead of 8. I am on Windows and my clock in taskbar shows the right time (PSDT).

Update: I found out that if you call strptime() as a Class method, instead of as an object method, GMT is assumed. Otherwise the object's timezone is used, i.e. changing:

$t = $t->strptime( $x, '%s' ); ## to:
$t = Time::Piece->strptime( $x, '%s' );
[download]

produces:

1.30
Input 1415998800
Output 1415998800
Fri Nov 14 21:00:00 2014
Fri, 14 Nov 2014 21:00:00 UTC
daylight savings flag is:0
[download]

Comment on Re: Time::Piece epoch parsing Select or Download Code

Replies are listed 'Best First'.
Re^2: Time::Piece epoch parsing by vsespb (Chaplain) on Jul 03, 2016 at 23:56 UTC
strptime() interprets the input value as a local time. It then subtracts 3 hours to get the output GMT epoch value. But why in the first place epoch interpreted as "local time"? Epoch is not about timezones. It cannot be local or GMT.. From man 7 strptime: %s The number of seconds since the Epoch, 1970-01-01 00:00:00 +0000 (UTC). Leap seconds are not counted unless leap second support is available. and number of seconds since specific moment of time is always same, independent of timezone I found out that if you call strptime() as a Class method, instead of as an object method, GMT is assumed Ok, behaviour differs. Great finding! thx	[reply]
Re^3: Time::Piece epoch parsing by Marshall (Canon) on Jul 04, 2016 at 01:10 UTC
I have no idea why this thing does what it does. But my "reverse engineering" appears to be sound: `(1415988000-1415998800)/60/60= -3 hrs Moscow time to GMT (1416027600-1415998800)/60/60= +8 hrs California time to GMT` [download] Almost all my work is done in GMT. I seldom convert to local time. This module appears to be pretty stupid about local time. I think there are much better modules for that task with better knowledge about time zones and daylight savings time. The good modules will even know about places that are 30 minutes instead of an hour off from the adjacent time zone.	[reply] [d/l]