reassign 566013 perl-modules tags 566013 + patch thanks Ugh... I sent myself ≥1000 messages, and could not reproduce this bug, they were all properly tagged as -0600. I had already started answering to this mail as "unreproducible".
In any case - Quoting Swaks' documentation, it does not generate the
date string by itself:
Date Manipulation
swaks generates an RFC compliant date string when it interpolates
the %D token in message bodies. In order to build the GMT offset
in this string, it needs the Time::Local module. It would be very
odd for this module not to be available because it has been
included in the perl distribution for some time. However, if it
is not loadable for some reason and swaks interpolates a %D token
(as it would when using the default body), the date string is in
GMT instead of your local timezone.
(... Looking a bit further into it)
In any case, the potentially offending code (that means, the code that
generates the date string - For the full code, /usr/bin/swaks lines
1532-1552) is:
sub get_date_string {
(…)
my @l = localtime();
(…)
my @g = gmtime();
$o = (timelocal(@l) - timelocal(@g))/36;
(…)
}
I live in GMT-6, so I tried this a couple tens of thousands of times:
$ perl -e '$|=1;use Time::Local; $sys_tz=`date +%z`*1; $i=0; while (1) {
@l=localtime(); @g=gmtime(); $o=(timelocal(@l) - timelocal(@g))/36; print "."
unless $i++%1000; print $o if $o ne $sys_tz}'
............................................................................................................................................................................................................................................................................................................-600.027777777778................................................-600.027777777778........................-600.027777777778........................................................................-600.027777777778............-600.027777777778..^C
I tried this as well on a computer running on UTC, and yes, I got
-0.0277777777777778 with a similar frequency. And, as expected, I
tried it on a computer on GMT+1 (asdfasdf.debian.net - Running
kfreebsd-amd64, so the issue must be on the Perl code), and got some
99.9722222222222 — As this number is rendered using a %+05d format
string in get_date_string, it becomes +0099, an invalid timezone.
So, I'm reassigning this bug to perl-modules, which contains
Time::Local. Given that the timezones are integers by definition, the
bug might be considered as fixable with:
--- /usr/share/perl/5.10.1/Time/Local.pm 2009-11-21 13:30:05.000000000
-0600
+++ /tmp/Local.pm 2010-01-27 10:21:17.000000000
-0600
@@ -177,7 +177,11 @@
my ( $s, $m, $h ) = localtime($loc_t);
$loc_t -= $dst_off if $s != $_[0] || $m != $_[1] || $h != $_[2];
- return $loc_t;
+ # Comparing two very-slightly-off readings of the clock yields a
+ # difference of -0.027777 seconds. Timezones are integers, and
+ # represent the number of seconds; round (don't truncate) the
+ # result as values ending with '99' are not valid.
+ return int($loc_t + 0.5);
}
sub timelocal_nocheck {
Greetings,
--
Gunnar Wolf • gw...@gwolf.org • (+52-55)5623-0154 / 1451-2244
signature.asc
Description: Digital signature
