>>>>> On Tue, 07 Apr 2009 16:45:54 +0200, Foo said:
>
> On Mon, 06 Apr 2009 19:41:52 +0200, Martin Simmons <martin AT lispworks DOT
> com>
> wrote:
>
> >>>>>> On Mon, 06 Apr 2009 17:34:09 +0200, Foo said:
> >>
> >> The best solution would be for Bacula to translate time to UTC
> >> internally
> >> for scheduling, everything external such as logfiles, scheduling stanzas
> >> in config etc. would remain in the user's locale.
> >
> > That doesn't help, because saying 2:05am local time in the config file is
> > still ambiguous if the local time moves backwards by 1 hour at 3:00am.
>
> Not really, UTC remains the same on DST changes, so internal events using
> UTC should be fine.
>
> Basically on startup Bacula needs to check the locale, get the offset from
> UTC, if any, and set its internal clock to UTC, and change the offset on
> DST changes. Then use the offset for calculations involving configs/user
> output like logging.
Doing all of those calculations doesn't solve the underlying problem, which is
that the user has entered ambiguous data by saying "run this at 2:05am local
time today." On the day of the DST change, there is no unique UTC for 2:05am
local time -- it might occur twice or not at all.
The problem is what should 2:05am mean in that case? E.g. is it 2 hours after
midnight or 10 hours before midday?
The code gets even more non-trivial when you also need to deal with clock
adjustment as well. See the first half of cron_tick in
http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/cron/cron/cron.c?rev=1.20
for example.
__Martin
------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|