Bug in timelocal?

[yocoyote]

I'm writing scripts which make heavy use of the timelocal() fct.
(Time::Local) to get epochtime from a MM/DD hh:mm:ss text date. I'm
using activestate perl 5.8.4 build 810 on my pc. I've found one date,
among the 10,000's I've successfully transformed, is offset by 3600
sec. The 3600 (=1 hour) struck me as not likely a conincidence. I'm
wondering if others have seen this before.

syntax:

use Time::Local
$epochTime = timelocal($sec, $min, $hour, $day, $month - 1);

Anyone seen instances in which a date, seemingly at random, has 3600
added or subtracted from the correct output of timelocal?

thanks
yocoyote

 

[Mothra]

(snipped)

using activestate perl 5.8.4 build 810 on my pc. I've found one date,

Which one? what was the date?

among the 10,000's I've successfully transformed, is offset by 3600
sec. The 3600 (=1 hour) struck me as not likely a conincidence. I'm
wondering if others have seen this before.

Mothra

 

[yocoyote]

Here are the dates: the diff is negative, which highlighted the issue
$MonthSTART = 04, $DaySTART = 02, $HourSTART = 02, $MinSTART = 47,
$SecSTART = 07
(04/02 02:47:07)
$epochTimeSTART = timelocal($SecSTART, $MinSTART, $HourSTART,
$DaySTART, $MonthSTART-1);
I get $epochTimeSTART = 954672427
---
$MonthSTOP = 04, $DaySTOP = 02, $HourSTOP = 03, $MinSTOP = 09, $SecSTOP
= 08
(04/02 03:09:08)
$epochTimeSTART = timelocal($SecSTART, $MinSTART, $HourSTART,
$DaySTART, $MonthSTART-1);
I get $epochTimeSTOP = 954670148

So the calculated diff ($epochTimeSTOP - $epochTimeSTART) = -2279
The correct diff (I did by hand) = 1321

Note that 2279 + 1321 = 3600 !

So either the $epochTimeSTART was shifted up an hour or $epochTimeSTOP
was shifted back an hour. These dates are close to daylight savings
time change in PST (where I'm at) but off by about 23 hrs.

 

[Brian McCauley]

I'm writing scripts which make heavy use of the timelocal() fct.
(Time::Local) to get epochtime from a MM/DD hh:mm:ss text date. I'm
using activestate perl 5.8.4 build 810 on my pc. I've found one date,
among the 10,000's I've successfully transformed, is offset by 3600
sec. The 3600 (=1 hour) struck me as not likely a conincidence. I'm
wondering if others have seen this before.

Was this is the week following the DST transion perhaps?

I discovered last week that on some versions of the Win32 OS there's a
but that sometimes causes it to report the wrong local time to some
applications in the week following the DST transition.

(Note: I didn't come across this in Perl but in another language).

Anyone seen instances in which a date, seemingly at random, has 3600
added or subtracted from the correct output of timelocal?

I can't recall the details but I did many years ago note that
Time::Local's algorithm was flawed. I don't know if it was ever fixed.

 

[Keith Keller]

$MonthSTART = 04, $DaySTART = 02, $HourSTART = 02, $MinSTART = 47,
$SecSTART = 07
(04/02 02:47:07)
$epochTimeSTART = timelocal($SecSTART, $MinSTART, $HourSTART,
$DaySTART, $MonthSTART-1);
I get $epochTimeSTART = 954672427
---
$MonthSTOP = 04, $DaySTOP = 02, $HourSTOP = 03, $MinSTOP = 09, $SecSTOP
= 08
(04/02 03:09:08)
$epochTimeSTART = timelocal($SecSTART, $MinSTART, $HourSTART,
$DaySTART, $MonthSTART-1);
I get $epochTimeSTOP = 954670148

So the calculated diff ($epochTimeSTOP - $epochTimeSTART) = -2279

Please post a complete, working Perl script. The above makes people
edit your code by hand in order to even start to help you.

--keith

 

[Mothra]

So either the $epochTimeSTART was shifted up an hour or $epochTimeSTOP
was shifted back an hour. These dates are close to daylight savings
time change in PST (where I'm at) but off by about 23 hrs.

I was unable to reproduce your problem.

use strict;
use warnings;
use Time::Local;

my @start = qw(07 47 02 02 03);
my @end = qw(08 09 03 02 03);

my $estart = timelocal(@start);
my $estop = timelocal(@end);

print "start time is: $estart\n";
print "End time is: $estop\n";

my $diff = $estop - $estart;

print "the difference is: $diff\n";


output is
F:\scripts>me.pl
start time is: 954672427
End time is: 954673748
the difference is: 1321

 

[Gary E. Ansok]

Here are the dates: the diff is negative, which highlighted the issue
$MonthSTART = 04, $DaySTART = 02, $HourSTART = 02, $MinSTART = 47,
$SecSTART = 07
(04/02 02:47:07)
$epochTimeSTART = timelocal($SecSTART, $MinSTART, $HourSTART,
$DaySTART, $MonthSTART-1);
I get $epochTimeSTART = 954672427
---
$MonthSTOP = 04, $DaySTOP = 02, $HourSTOP = 03, $MinSTOP = 09, $SecSTOP
= 08
(04/02 03:09:08)
$epochTimeSTART = timelocal($SecSTART, $MinSTART, $HourSTART,
$DaySTART, $MonthSTART-1);
I get $epochTimeSTOP = 954670148

So the calculated diff ($epochTimeSTOP - $epochTimeSTART) = -2279
The correct diff (I did by hand) = 1321

Note that 2279 + 1321 = 3600 !

So either the $epochTimeSTART was shifted up an hour or $epochTimeSTOP
was shifted back an hour. These dates are close to daylight savings
time change in PST (where I'm at) but off by about 23 hrs.

This might help clear up your confusion:
print scalar localtime $epochTimeSTART;

Why do you not specify a year in your call to timelocal()? Do you
know what timelocal() uses when you don't specify a year?

Yes, it is a DST time changeover issue. No, it's not a bug.
"If the timelocal() function is given a non-existent local time,
it will simply return an epoch value for the time one hour later."

Gary Ansok

 

[Gary E. Ansok]

This might help clear up your confusion:
print scalar localtime $epochTimeSTART;

Why do you not specify a year in your call to timelocal()? Do you
know what timelocal() uses when you don't specify a year?

I might add that if you had had Perl's warnings turned on, you would
have gotten messages that might have led you to the correct answer
without needing outside help.

Gary

 

[yocoyote]

Thank you. Thank you.

By explicitly adding the year to the timelocal() call, I get the
correct value of 1321.

I am still trying to reconcile some of the comments above (clearly
accurate) with the details of how this occurred, i.e., early on a Sat
morning (not Sun) and the time ($epochStopTime was affected) seemed to
move back, rather than forward ("spring forward")

-yocoyote

 

[yocoyote]

definitely good input and consistent with all the books i've read.
what i don't understand is which i didnt get the warnings because i had
"use warnings;" at the top of my code.
i get no warnings with or without the -c at the command prompt ??

at any rate, thanks again

 

[brian d foy]

Here are the dates: the diff is negative, which highlighted the issue
$MonthSTART = 04, $DaySTART = 02, $HourSTART = 02, $MinSTART = 47,
$SecSTART = 07

You're missing an hour on the day that daylight savings starts?
That's odd.

 

[Gary E. Ansok]

Thank you. Thank you.

By explicitly adding the year to the timelocal() call, I get the
correct value of 1321.

I am still trying to reconcile some of the comments above (clearly
accurate) with the details of how this occurred, i.e., early on a Sat
morning (not Sun) and the time ($epochStopTime was affected) seemed to
move back, rather than forward ("spring forward")

Did you try the line I suggested:

print scalar localtime $epochTimeSTART;

I get
Sun Apr 2 03:09:08 2000

If you don't supply a year to timelocal(), it gets undef as the
year value. When that is used numerically, it becomes a 0.
If you read the docs for Time::Local, you'll find that 0 is
treated as 2000 (until 2050, when 0 will be treated as 2100).

While it might be useful in some cases for timelocal() to assume
the current year if none is supplied, it doesn't. You could write
to the maintainer and suggest the behavior you want.

Gary

 

[Gary E. Ansok]

definitely good input and consistent with all the books i've read.
what i don't understand is which i didnt get the warnings because i had
"use warnings;" at the top of my code.
i get no warnings with or without the -c at the command prompt ??

Ah. Since I was running this as a quick one-liner at the command prompt,
I used -w (which turns on warnings everywhere). You used "use warnings",
which turns on warnings in the file or block where it appears.

These warnings are generated within Time::Local, which explains why I
saw them and you didn't.

Both have advantages and disadvantages, but "use warnings" is probably
the better way to go overall.

Gary

 

[Bart Lateur]

I'm writing scripts which make heavy use of the timelocal() fct.
(Time::Local) to get epochtime from a MM/DD hh:mm:ss text date. I'm
using activestate perl 5.8.4 build 810 on my pc. I've found one date,
among the 10,000's I've successfully transformed, is offset by 3600
sec. The 3600 (=1 hour) struck me as not likely a conincidence. I'm
wondering if others have seen this before.

Daylight Savings Time. It must be the difference in start/end dates,
between the DST in 1970, and this year.

Use gmtime()/timegm(), and you won't have that.

 

[Joe Smith]

You're missing an hour on the day that daylight savings starts?
That's odd.

Actually, missing an hour on the day that daylight savings started
four years ago, which is a different day of the month than this year.