-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dan Langille wrote:
> On 20 Aug 2007 at 0:40, Ryan Novosielski wrote:
>
>> Dan Langille wrote:
>>> On 18 Aug 2007 at 11:00, Ryan Novosielski wrote:
>>>
>>>> Dan Langille wrote:
>>>>> On 18 Aug 2007 at 2:00, Per olof Ljungmark wrote:
>>>>>
>>>>>> Since upgrading to 2.2.0 bsmtp sets the wrong Date: header in the mail:
>>>>>> Date: Sat, 18 Aug 2007 01:48:56 +0000 (CEST)
>>>>>>
>>>>>> For the recipient the above message appears to have been receieved at
>>>>>> 03:48, two hours ahead.
>>>>>>
>>>>>> The correct timezone is UTC +2, the above header should have read
>>>>>> Date: Sat, 18 Aug 2007 01:48:56 +0200 (CEST)
>>>>>> ^
>>>>>> Again, this might be FreeBSD specific just as my last report.
>>>>> This just in (at 23:22 local time):
>>>>>
>>>>> Date: Fri, 17 Aug 2007 23:19:12 +0000 (EDT)
>>>>>
>>>>> Compare that to an email generated via: echo 'test' | mail dan
>>>>>
>>>>> Fri, 17 Aug 2007 23:21:39 -0400 (EDT)
>>>>>
>>>>> It's getting the timezone wrong. In my case, it should be -0400. I
>>>>> won't have time to look at this until Saturday afternoon.
>>>> I'd like to chime in that it is NOT just FreeBSD, but at least also
>>>> Solaris. I've had this problem with Solaris and Horde/IMP before as
>>>> well, so I never reported it on the Bacula list figuring it was really
>>>> not their problem. My Bacula director is Solaris 9. I don't know how 10
>>>> would change this.
>>> Good. Good to know. Thank you.
>>>
>>> Perhaps it was this commit:
>>>
>>> http://bacula.svn.sourceforge.net/viewvc/bacula/trunk/bacula/src/tools
>>> /bsmtp.c?view=diff&r1=4789&r2=479
>>>
>>> If you look at older versions of bsmtp, and I think that's where the
>>> problem is, you see this (look around line 353):
>>>
>>> http://bacula.svn.sourceforge.net/viewvc/bacula/trunk/bacula/src/tools
>>> /bsmtp.c?view=diff&r1=2835&r2=283
>>>
>>> The code used to do:
>>>
>>> strftime(buf, sizeof(buf), "%a, %d %b %Y %H:%M:%S %z", &tm)
>>>
>>> Where the %z (time zone offset, e.g. -04) is the time zone. For some
>>> reason, this is now done as a different step (see the first URL) and
>>> uses %Z (time zone name, eg. EST)
>>>
>>> This patch fixes the problem for me, but I suspect there were some
>>> special issues attempted by the original code that my fix does not
>>> address.
>>>
>>> --- src/tools/bsmtp.c~ Sat Aug 18 16:33:26 2007
>>> +++ src/tools/bsmtp.c Sat Aug 18 16:33:26 2007
>>> @@ -194,11 +194,7 @@
>>> gettimeofday(&tv, &tz);
>>> my_timezone = tz.tz_minuteswest; /* timezone offset in mins */
>>> #endif
>>> - strftime(buf, buf_len, "%a, %d %b %Y %H:%M:%S", &tm);
>>> - sprintf(tzbuf, " %+2.2ld%2.2u", -my_timezone / 60,
>>> abs(my_timezone) % 60);
>>> - strcat(buf, tzbuf); /* add +0100 */
>>> - strftime(tzbuf, sizeof(tzbuf), " (%Z)", &tm);
>>> - strcat(buf, tzbuf); /* add (CEST) */
>>> + strftime(buf, buf_len, "%a, %d %b %Y %H:%M:%S %z %Z", &tm);
>>> }
>> I haven't had a lot of time to look this over, but I think that the date
>> in my headers from bstmp will be interesting to you and others who may
>> be having this problem and have had more time to look at it:
>>
>> Date: Sun, 08 Jul 2007 23:57:00 +0000 (%z)
>>
>> ...that don't look right to me. :) I suspect %z and %Z may not be
>> handled properly on non-Linux? Is that even possible? I thought most of
>> this stuff kinda stuck to POSIX for this kind of thing, whatever it
>> might have to say about this. <shrug>
>
> Ryan: please check man strftime and compare to what I found here for
> %z: http://bama.ua.edu/cgi-bin/man-cgi?00+00
>
> In short, %Z is supported on Solaris, but not %z.
And it would appear that %Z does not mean what it should mean as far as
bsmtp/Solaris is concerned:
%Z Time zone name or abbreviation, or no bytes if no time
zone information exists.
Besides, what exactly does "name or abbreviation" mean? How does one
know which to expect?
In any case, after having looked on Google some for this, it looks like
the solution may be to drop (%z) altogether. Is that portable? Not sure.
The only other way would seem to be to test for strftime's ability to do
%z (it looks like there are other OS' that cannot handle it either) in
configure. I should at least mention this probably to the folks on
Blastwave, as their package needs a patch.
=R
- --
---- _ _ _ _ ___ _ _ _
|Y#| | | |\/| | \ |\ | | |Ryan Novosielski - Systems Programmer II
|$&| |__| | | |__/ | \| _| |[EMAIL PROTECTED] - 973/972.0922 (2-0922)
\__/ Univ. of Med. and Dent.|IST/AST - NJMS Medical Science Bldg - C630
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGya7Nmb+gadEcsb4RAg3rAKCERR03OHuAk40EyTJ6O7rAlgte+QCg2HVW
m3eaY2DznHoho4OdDzpDZ5k=
=8KJ5
-----END PGP SIGNATURE-----
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
