On Tue, 07 Apr 2009 20:23:49 +0200, Martin Simmons <mar...@lispworks.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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
