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
