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.

> To resolve this, Bacula would have to use UTC in the config file as well.

See above.

> Alternatively, it would need some non-trivial code to deal with the
> duplicate/missing local times.

I don't see how this is not trivial code. I would assume some standard  
library/system clock routines are used for time, just put a filter routine  
in between and call that instead (hopefully this should be a search and  
replace in the code).


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