On Mon, 06 Apr 2009 19:41:52 +0200, Martin Simmons <mar...@lispworks.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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
