On Dec 3, 2008, at 10:25 , [EMAIL PROTECTED] wrote:
>Yes. There are 2 hours each year when this formula is wrong.
I assume you're thinking of the switch from DST to CST and vice-
versa, yes? But since that change occurs at oh-dark-hundred
(2:00AM), it's already "today," and "yesterday" would be the same,
wouldn't it? Or is it a different pair of hours you're referring to?
This occurs on the 23th hour in the fall and the 0th hour in the
spring. This program shows a brute force way to find these that might
convince you:
------------------------
$h = 60 * 60;
$end = time + 366 * 24 * $h;
for ($t = time; $t < $end; $t += 0.5 * $h) {
print scalar(localtime($t)), "\n" if day($t) eq day($t + $h) &&
day($t - 24 * $h) ne day($t + $h - 24 * $h);
}
sub day {
my($y, $m, $d) = (localtime shift)[5,4,3];
$y += 1900;
$m += 1;
return sprintf "%04d-%02d-%02d", $y, $m, $d;
}
------------------------
More seriously, isn't this code subtracting a day twice?
True. That's a bug.
>>>> my ($mday, $mon, $year) = (localtime(time() - 60 * 60 * 24) )
[ 3,4,5];
>>>> printf("%d/%02d/%02d\n", $year + 1900, $mon + 1, $mday - 1);
I would think that the first, subtracting from time() would be the
correct one--the one that would overcome changes in month, year, and
time, while the second, from $mday's value, is not just redundant,
but at this point, wrong, no? Not only that, it would introduce such
curiosities as the zero-th day of each month--the day before the
first of a month.
On a picky note, wouldn't it be easier to just subtract 86400?
Easier to type perhaps but possibly not easier to most people to
recognize as correct. For Perl it does not matter as it will fold
constants at compile time and execute exactly the same code. Try:
perl -MO=Deparse -e "print time + 24 * 60 * 60"
--Gisle
_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
