>>>>> On Tue, 07 Apr 2009 16:45:54 +0200, Foo said: > > 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.
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
