Hi!
I'm in an argument with a coworker about whether a program must gracefully
handle jumps in the system time. The jumps occur when, for demonstrating
logfile cleanup, people set the time a year ahead or back. This
test-procedure is part of a validation, so not really easy to change.

The problem is that certain threads that poll things wait between polls for
e.g. a second. If, in that waitcycle, the systemtime is rewound by a year,
it will wait virtually forever.

My point of view is that this is not a normal working condition and it is
perfectly valid to require a reboot for the clock change. Related to that,
can anyone give examples for programs that are either designed to handle
this gracefully or known no fail under such circumstances? Im particularly
interested in typical services running on MS Windows >= NT 5.0 and Debian
GNU/Linux, both configured to be rather 'embeddish'.

I know that NTP clients are written so that they don't create jumps in
systemtime. They rather accelerate or slow down the systemtime until it
reaches the target setting.

thank your for any pointer

Uli

"Ulrich Eckhardt" <doomster@knuut.de> wrote in message
news:2pger5Fklv98U1@uni-berlin.de...
> Hi!
> I'm in an argument with a coworker about whether a program must gracefully
> handle jumps in the system time. The jumps occur when, for demonstrating
> logfile cleanup, people set the time a year ahead or back. This
> test-procedure is part of a validation, so not really easy to change.
>
> The problem is that certain threads that poll things wait between polls
for
> e.g. a second. If, in that waitcycle, the systemtime is rewound by a year,
> it will wait virtually forever.

Hello.

So far I have never seen a service failing with a time change, so I suppose
they are made to handle this. After all, it is, in many cases, not even
complicated. If there is a fixed point in time, where something has to
happen (e.g. a scheduled event), there is no need to time-adjust it (if it
was to run on 2004/9/21, there's no reason to run it on 2003/9/21). If
however the goal is to wait for a fixed period of time (e.g. 1 second
between polls), you do not have to tie it to a certain point in time, just
use the system-provided wait functions like SleepEx(1000,false) for a 1
second delay, the system functions will handle the time jumps correctly by
themselves. If you need to be aware of time jumps however, you can use some
code like the following (Windows, any version, don't forget to #include
<windows.h>):

//------------------------------------------------------

typedef void (WINAPI *TimeChangeNotification)(LONGLONG Milliseconds);

void WINAPI Timer(LONGLONG Milliseconds)
{
  // Do something when the time changes ...
}

DWORD WINAPI ThreadProc(LPVOID ThreadParam)
{
  SYSTEMTIME BaseSysTime;
  LONGLONG BaseFileTime;
  SYSTEMTIME SysTime;
  LONGLONG FileTime;
  while(true)
  {
    GetSystemTime(&BaseSysTime);
    SystemTimeToFileTime(&BaseSysTime,(LPFILETIME)&BaseFileTime);
    SleepEx(1000,false);
    GetSystemTime(&SysTime);
    SystemTimeToFileTime(&SysTime,(LPFILETIME)&FileTime);
    LONGLONG TimeDelta = ((FileTime - BaseFileTime) / 10000) - 1000;
    if((TimeDelta > 10000)||(TimeDelta < -10000))
    {
      TimeChangeNotification Timer = (TimeChangeNotification)ThreadParam;
      if (Timer) Timer(TimeDelta);
    }
  }
}

BOOL WINAPI StartThread(TimeChangeNotification TimerProc)
{
  DWORD dwThreadID = 0;
  HANDLE hThread = CreateThread(0,0,&ThreadProc,TimerProc,0,&dwThreadID);
  if (!dwThreadID || !hThread) return false;
  SetThreadPriority(hThread,THREAD_PRIORITY_ABOVE_NORMAL);
  CloseHandle(hThread);
  return true;
}

void Start(void)
{
  StartThread(Timer);
}


//------------------------------------------------------

It repeatedly waits for one second and whenever it sees a change of more
than ten seconds, it complains by calling the Timer function with an
estimated difference in milliseconds. It would than have to cancell the
waits if some are pending. Start the whole thing by calling Start once at
app startup and it will continue to run until the app terminates.

Dimitrij

Ulrich Eckhardt wrote:
> 
> I'm in an argument with a coworker about whether a program must
> gracefully handle jumps in the system time. The jumps occur when,
> for demonstrating logfile cleanup, people set the time a year
> ahead or back. This test-procedure is part of a validation, so
> not really easy to change.
> 
> The problem is that certain threads that poll things wait between
> polls for e.g. a second. If, in that waitcycle, the systemtime is
> rewound by a year, it will wait virtually forever.
> 
> My point of view is that this is not a normal working condition
> and it is perfectly valid to require a reboot for the clock
> change. Related to that, can anyone give examples for programs
> that are either designed to handle this gracefully or known no
> fail under such circumstances? Im particularly interested in
> typical services running on MS Windows >= NT 5.0 and Debian
> GNU/Linux, both configured to be rather 'embeddish'.
> 
> I know that NTP clients are written so that they don't create
> jumps in systemtime. They rather accelerate or slow down the
> systemtime until it reaches the target setting.

I more or less agree with you.  However any decent multitasking or
multithreading etc. OS will require that altering the system clock
be a privileged operation for just this reason, so the problem
should not arise.

Many systems also provide a 'time since boot' value, which can not
be arbitrarily reset.  You might consider using that in place of
the clock time.

-- 
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Hello,

Ulrich Eckhardt wrote:

> Hi!
> I'm in an argument with a coworker about whether a program must gracefully
> handle jumps in the system time.

In multi threaded programs, using the well defined boost::thread library
(www.boost.org), the system time is used in order to wait and yield
processing to other threads. For example, I use 

#define my_sleep(x) do {CTime t(utcTime); t+=x;
boost::thread::sleep(t.Get_xtime());} while(0)

where CTime is just a class around a time value. my_sleep(anyTimeValue)
would wait for one year, if the user would change the system time by one
year. 

I think, at least for unix systems it is not a good idea to change the
system time. It should only be changed when the computer is restarted.

There are also functions in the linux kernel which are used in order to
adjust the system time slowly by making the clock a little bit faster or
slower.

Last but not least, only the superuser (administrator) is allowed to change
the system time on my linux distribution and also on my windows 2000 pc. 

Greetings

Ernst


-- 
Ernst Murnleitner
www.awite.com

CBFalconer wrote:

<snip>
> I more or less agree with you.  However any decent multitasking or
> multithreading etc. OS will require that altering the system clock
> be a privileged operation for just this reason, so the problem
> should not arise.

Except perhaps for daylight savings transition, which messed me up 
rather nastily one time :)

> Many systems also provide a 'time since boot' value, which can not
> be arbitrarily reset.  You might consider using that in place of
> the clock time.

This is indeed useful for timing events based on elapsed time rather 
than clock time... certainly more useful than a clock time that can be 
altered :)

On Windows the GetTickCount() API is fine for most things of this 
nature... within limits.

And as someone already noted, events scheduled by clock-time can 
generally be safely left alone... although daylight savings transitions 
can cause double execution.

-- 
Corey Murtagh
The Electric Monk
"Quidquid latine dictum sit, altum viditur!"

"Ulrich Eckhardt" <doomster@knuut.de> wrote in message 
news:2pger5Fklv98U1@uni-berlin.de...
> Hi!
> I'm in an argument with a coworker about whether a program must gracefully
> handle jumps in the system time.

Yes, they should.

My Mac recently, after a power outage, decided it was 1969.

On bootup and login, the iCal calendar program started up,
as usual.

When the system was able to connect with a time server and
correct the time and date, iCal proceeded to display and mail
me two years' worth of appointment reminders.

So, yes, programs should gracefully handle jumps in system
time. At least sometimes, depending on the program.