On Tue, 07 Apr 2009 20:23:49 +0200, Martin Simmons <martin AT lispworks DOT 
com>  
wrote:

>>>>>> On Tue, 07 Apr 2009 16:45:54 +0200, Foo  said:
>>
>> 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.

I'm just guessing here but this would seem logical to me: when Bacula  
(re)loads the config, it parses the Schedule {} stanzas and puts them in  
an array, then it does a neverending sleep/check loop to see if the  
current time occurs in the array and if so executes the associated job.

I'm proposing to remap the schedule array to UTC and check against UTC  
current time. Since neither changes during the course of the year, every  
scheduled job is executed exactly once, and always - unless the config is  
changed/reloaded exactly during a DST change period, but that's up to the  
user to deal with.

The trick is while doing the mapping, you look at whether the schedule  
would fall in/on a DST change period/second or not. If so, then map it so  
it occurs on the UTC time equivalent to the 'first' local time (for  
changes backwards) or immediately after the change (for changes forwards,  
possibly offset by the same amount in the hour), i.e. a job scheduled for  
02:05 local time would occur at 02:05 364 times a year (at the 'first  
02:05' on summer to wintertime change day), and at 03:00 (or 03:05) once a  
year.

Obviously this would mean instead of having a static array as large as  
there are schedules, a dynamic array that needs to be calculated ahead of  
time for a certain period and refilled every so often (e.g. FIFO every 24  
hours). This might cost some extra memory but can be scaled if needed,  
down to 1 hour and a second basically.

> The problem is what should 2:05am mean in that case?  E.g. is it 2 hours  
> after midnight or 10 hours before midday?

It is 02:05+$offset UTC :)

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

I haven't thoroughly read the code so I'll assume it is an example of  
dealing with time/offset changes by checking whether current time <  
previous time instead of the above proposal.


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