On Thursday 23 August 2007 11:58, Attila Fülöp wrote:
> Martin Simmons wrote:
> >>>>>> On Wed, 22 Aug 2007 14:07:26 +0200, Kern Sibbald said:
> >>
> >> On Wednesday 22 August 2007 13:58, Martin Simmons wrote:
> >>>>>>>> On Tue, 21 Aug 2007 21:07:49 +0200, Kern Sibbald said:
> >>>>
> >>>> Hello again,
> >>>>
> >>>> By the way, in the bug report, please show the date generated by both
> >>>> the mail (or Mail) and bsmtp commands. On my machine the dates seem
> >>>> to be correct. Perhaps postfixing (CEST) confuses someone's email
> >>>> program as that is the only difference between mail and bsmtp (bsmtp
> >>>> has an extra (CEST) added).
> >>>
> >>> Try setting TZ=EST5EDT. That should put -0400 as the offset, but on
> >>> Linux I always get the local offset including dst.
> >>>
> >>> Also, on FreeBSD I always get +0000 regardless of TZ (probably the
> >>> local offset without dst).
> >>>
> >>> The basic problem is that gettimeofday() doesn't set the tz_minuteswest
> >>> from the TZ variable.
> >>
> >> If that is the case (tz_minuteswest not set), then the bug would seem to
> >> be in your OS' gettimeofday() implementation.
> >
> > Mine and yours (if you are running Linux) :-)
> >
> > BSD-like OS's store this info in the tm.tm_gmtoff field set by
> > localtime().
> >
> > I think the tz_minuteswest was always historically set to the "kernel"
> > timezone anyway, because gettimeofday() is a system call. The complexity
> > of TZ and the zoneinfo databases is only handled in the userspace by
> > functions such as localtime().
> >
> > __Martin
>
> The same is true for solaris It is reflected in the prototype
> int gettimeofday(struct timeval *tp, void *tzp);
> Looking at the different timezone handling among Solaris, FreeBSD and Linux
> i would say the most portable solution for getting the timezone offset is
> along the lines of the code below:
Many thanks. I *really* like this kind of submission. I will test it, and
very likely add it to bsmtp. More later ...
Kern
>
> #include <stdio.h>
> #include <time.h>
>
> /* Return the offset west from localtime to UTC in minutes
> * Same as timezone.tz_minuteswest
> */
>
> int tz_offset ()
> {
> time_t now = time (NULL);
> struct tm tm_utc, tm_lcl;
>
> (void) localtime_r (&now, &tm_lcl);
> (void) gmtime_r (&now, &tm_utc);
> tm_utc.tm_isdst = tm_lcl.tm_isdst;
> return difftime (mktime (&tm_utc), now) / 60;
> }
>
> This code is tested, one should add proper error handling though.
>
> Attila
>
> >> Can you send me a copy of the FreeBSD gettimeofday() man page?
> >>
> >>> __Martin
> >>>
> >>>> On Tuesday 21 August 2007 19:59, Dan Langille wrote:
> >>>>> FYI, a proposed solution for the date problem.
> >>>>>
> >>>>> ------- Forwarded message follows -------
> >>>>> From: "Dan Langille" <[EMAIL PROTECTED]>
> >>>>> To: Ryan Novosielski <[EMAIL PROTECTED]>
> >>>>> Date sent: Tue, 21 Aug 2007 13:55:03 -0400
> >>>>> Priority: normal
> >>>>> Copies to: [EMAIL PROTECTED]
> >>>>> Subject: Re: [Bacula-users] wrong date in mail report
> >>>>> with
> >>>>> 2.2.0
> >>>>>
> >>>>> [ Double-click this line for list subscription options ]
> >>>>>
> >>>>> On 21 Aug 2007 at 12:47, Ryan Novosielski wrote:
> >>>>>> 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/
> >>>>>>>>> tool s /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/
> >>>>>>>>> tool s /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.
> >>>>>>
> >>>>>> Changing this %z to %Z (actually, on 2.0.3 I think it was changing
> >>>>>> '%Z (%z)' to just %Z) rectifies the problem on Solaris 9, which is
> >>>>>> nice, because I was really sick of doing the math every time my
> >>>>>> backups finished.
> >>>>>
> >>>>> I am tempted to change the code to use %Z. It seems to be more
> >>>>> portable and exists on all the man strftime pages that I've checked.
> >>>>>
> >>>>> Either that or add an autoconf test. Which I don't know how to do.
> >>>>> If someone does that work, I'll be sure to add it in.
> >>>>>
> >>>>> If no objections, I'll do the %Z patch tomorrow. And, FYI, I'll
> >>>>> patch the 2.2.0 code in the Bacula port.
> >>>>>
> >>>>> --
> >>>>> Dan Langille - http://www.langille.org/
> >>>>> Available for hire: http://www.freebsddiary.org/dan_langille.php
> >>>>>
> >>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>>- ---
> >>>>> 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
> >>>>> [EMAIL PROTECTED]
> >>>>> https://lists.sourceforge.net/lists/listinfo/bacula-users
> >>>>>
> >>>>>
> >>>>> ------- End of forwarded message -------
> >>>>
> >>>> ----------------------------------------------------------------------
> >>>>--- 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-devel mailing list
> >>>> [email protected]
> >>>> https://lists.sourceforge.net/lists/listinfo/bacula-devel
> >
> > -------------------------------------------------------------------------
> > 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-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/bacula-devel
>
> -------------------------------------------------------------------------
> 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-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bacula-devel
-------------------------------------------------------------------------
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-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-devel
