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]

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]

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]

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

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.

use strict;
use warnings;
use Time::Piece;

my $e = time();
my $t = Time::Piece->new($e);
print Time::Piece->VERSION, "\n";

print "Input $e\n";
print "Output ".$t->epoch(), "\n";
print $t, "\n";
print $t->strftime, "\n";
[download]

I am not looking for way to parse epoch, I am investigating why strptime with %s works wrong.

I am not looking for way to parse epoch, I am investigating why strptime with %s works wrong.

Um, strptime is a function that (I think) is short for string-parse-time, and %s is the field descriptor for epoch, so I think you are trying to parse an epoch, whether you realize it or not.

I am not looking for way to parse epoch, I am investigating why strptime with %s works wrong.

Look at the source, IIRC its a call to the underling C Runtimes strptime function, they're not all the same

#! /usr/bin/perl
use warnings;
use strict;

use Time::Piece;

print 'Time::Piece'->VERSION, "\n";
my $t = 'Time::Piece'->strptime($ARGV[0], '%s');
print "Input  $ARGV[0]\n";
print "Output ", $t->epoch(), "\n";
print $t, "\n";
print $t->strftime('%a %b %d %T %Y'), "\n";
[download]

Test run:

Indeed. Thanks!

strptime() called from language C gives the very same result.

/* cc -Wall -g strp.c -o strp */
#define _XOPEN_SOURCE
#include <time.h>
#include <stdio.h>

int main(int argc, char *argv[])
{
    struct tm tm;
    char *c;

    c = strptime(argv[1], "%s", &tm);

    printf("%s", asctime(&tm));

    return 0;
}
[download]

$ TZ=MSK ./strp 1415998800
Fri Nov 14 21:00:00 2014
[download]

Not really:

$ TZ=Europe/Moscow ./strp 1415998800
Sat Nov 15 00:00:00 2014
[download]