>>>>> 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