Martin Simmons wrote: >>>>>> 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? >
This is the crux of the problem. For time zones that have DST, there are ambiguous times caused by the two yearly time shifts. Worse, they have to be dealt with differently in Spring than in Fall. There are basically 3 methods for each: Spring forward causes there to be non-existent local times between 02:00:00 and 02:59:59, assuming the time shift occurs at 02:00:00 local time. The possibilities for handling these times are: 1. Skip them altogether. 2. Special treatment to translate 02:mm:ss to 03:mm:ss for these times only. 3. Compress time. Attempt to translate 02:mm:ss to 03:mm:ss, but decrement the actual time such that events specified as 02:mm:ss end up scheduled before any events scheduled between 03:00:00 and 03:59:59. The third option is the only way to ensure that events happen in the same order on the day the time shifts, though the time between events in the range 02:00:00 - 03:59:59 may be compressed. Fall back causes times between 01:00:00 and 01:59:59 to repeat, again assuming the time shift occurs at 02:00:00 local time. The possibilities for handling these times are: 1. Allow them to be scheduled twice. 2. Special treatment to translate 01:mm:ss to 02:mm:ss for these times only. 3. Expand time. Schedule nothing for the first hour following the time shift, forcing the events scheduled for these times to fire for only the first occurrence of the wall clock time. The third option ensures that events happen in order, but expands the time between 01:mm:ss events and 02:mm:ss events by an hour. This is most definitely a non-trivial problem. DST greatly complicates schedulers. Only governments can create chaos from something as orderly as time. > 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 > ------------------------------------------------------------------------------ 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