Front page | perl.perl5.porters |
Postings from November 2003
Wrong time base in Time::Piece? + other bugs
Thread Next
From:
Christian Jaeger
Date:
November 12, 2003 14:27
Subject:
Wrong time base in Time::Piece? + other bugs
Message ID:
p04320421bbd85dee0ea2@[192.168.3.11]
Hello
I don't understand this:
use strict;
use Time::Piece;
my $time=time();
print "time=$time\n";
my $d= Time::Piece->strptime($time,'%s');
my $epoch= $d->epoch;
print "epoch=$epoch\n";
print "diff: ".($time-$epoch)."\n";
__END__
time=1068561586
epoch=1068565186
diff: -3600
Why is there a difference? Is this a bug in the %s parsing function
(this is on (not fully current) Debian unstable, glibc 2.3.2,
Time::Piece 1.08), or does Time::Piece use a wrong base for it's
internal time storage format?
$d->strftime('%Y%m%dT%H%M%S%z')
shows +0100 as time zone value (which I think is correct).
As far as I understand, all parsing functions seem to assume
localtime (at least that's what it looks like when seeing +0100 as
%z); but the epoch value also returns a time that is "based" on
1970-1-1T0:00 localtime, same thing with %s parsing, while unixtime
should be based on 1970-1-1T0:00 GMT, right?
BTW there are two (other) bugs in Time::Piece:
- it blesses to Time::Piece instead of the $class value obtained from
the method arguments. This makes it necessary for subclasses to
override all creators and rebless the objects after calling the
SUPER:: creator.
- iirc, some methods modify the object itself, but return a copy of
it - or something similar - which is silly, since you think, "oh, I
got a copy, so I can still use the old one with the old value?", but
it's wrong, and if you think, "oh, it modified my old object - let's
modify the returned object again, it will change my original object
again", and it's wrong, too. I'd have to dig about it for a test case
if needed.
Christian.
Thread Next
-
Wrong time base in Time::Piece? + other bugs
by Christian Jaeger