Bacula-users

Re: [Bacula-users] Howto recover from a job being rerun around a summer time change

2009-04-08 10:03:14
Subject: Re: [Bacula-users] Howto recover from a job being rerun around a summer time change
From: Josh Fisher <jfisher AT pvct DOT com>
To: Martin Simmons <martin AT lispworks DOT com>
Date: Wed, 08 Apr 2009 09:59:23 -0400
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 <martin AT lispworks DOT 
>> 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 AT lists.sourceforge DOT 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 AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users