in reply to Time::Piece wierdness - sanity check please!

You are trying to use the string returned by a scalar context call to locatime() as the integer unix epoch time you really mean. You can't add ONE_HOUR to 'Sat Mar 6 01:55:26 2004' and get what you want! 

my $time = localtime;  # you mean $time = time();
print $time, $/;
$time = time();
print $time, $/;
__DATA__
Sat Mar  6 01:55:26 2004
1078538126

[download]

cheers

tachyon

Replies are listed 'Best First'.
Re: Re: Time::Piece wierdness - sanity check please!
by jdtoronto (Prior) on Mar 06, 2004 at 02:05 UTC
    Time::Piece over-rides localtime and gmtime, ONE_HOUR is a constant exported by Time::Seconds.

    $t = localtime - returns an object which, when stringified, behaves the same as the original localtime.

    The time arithmetic is not the problem, the problem is when you parse a datetime you get a value which is being treated as though it were GMT. Hence the difference values being calculated later which are 5 hours greater than the actual difference between the times.

    jdtoronto

[reply]
      Yes, I get equivalent results -- I seem to be in the same time zone as you, and get a similar 5-hour "padding" of the difference between "localtime" and a given time string passed to either "from_mysql_datetime" or "strptime". Regarding this latter method, the Time::Piece man page says "see the [unix] strptime man page", and when I looked at that (on MacOSX BSD), it said "The resulting values will be relative to the local time zone." But it looks like Time::Piece is not treating it as such -- instead, it's treating the values as relative to GMT -- and so is behaving badly (or at least counter to apparent intention, which is bad).
[reply]

In Section Seekers of Perl Wisdom