clock() and adjusting system time

Hi,
I was looking at a problem that was recently discovered with a program I
wrote. It has to do with when someone adjusts the system clock (using date
and rtc), the clock() function gets confused. I checked the return value of
clock() and it was returning -1.

I vaguely remember some kind of problem related to clock() when the system
time gets changed, and what it thinks the time really is. Is the clock()
getting confused because it’s start time compared to the current time is too
long? What might I do to prevent it from doing so if it is?

Thanks,
Ron

I just found a doc about the clock_t running out after 49 days in the
knowledge base, and a way to work around the issue.



“Ron Cococcia” <ude.ipr.sc@rcococ.nospam> wrote in message
news:ae3337$ku0$1@inn.qnx.com

Hi,
I was looking at a problem that was recently discovered with a program I
wrote. It has to do with when someone adjusts the system clock (using
date
and rtc), the clock() function gets confused. I checked the return value
of
clock() and it was returning -1.

I vaguely remember some kind of problem related to clock() when the system
time gets changed, and what it thinks the time really is. Is the clock()
getting confused because it’s start time compared to the current time is
too
long? What might I do to prevent it from doing so if it is?

Thanks,
Ron

Ron Cococcia <ude.ipr.sc@rcococ.nospam> wrote:

Hi,
I was looking at a problem that was recently discovered with a program I
wrote. It has to do with when someone adjusts the system clock (using date
and rtc),

BTW, that’s a nasty harsh thing to do to a running system. You generally
don’t want sudden jumps in system time, especially backwards, elapsed
times or rate calculations can give you divide by zero errors or other
messiness.

Take a look at qnx_adj_time() for a smoother way to update the current
system time, and at writing your own application to keep time “synched”
if you need to – or take a look at ntp.

Also, I think the rtc source code is availabe, if you want sample code
for verifying the time against the BIOS clock. (As your (more) accurate
time source.)

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

Ron Cococcia <ude.ipr.sc@rcococ.nospam> wrote:
: Hi,
: I was looking at a problem that was recently discovered with a program I
: wrote. It has to do with when someone adjusts the system clock (using date
: and rtc), the clock() function gets confused. I checked the return value of
: clock() and it was returning -1.

: I vaguely remember some kind of problem related to clock() when the system
: time gets changed, and what it thinks the time really is. Is the clock()
: getting confused because it’s start time compared to the current time is too
: long? What might I do to prevent it from doing so if it is?

Steve McPolin once described clock() as brain-dead. Here’s a note that
was added to the docs at some point since they were released:

The clock() function simply returns the difference between the
current time and the time the program started, so it gives
incorrect results if the system time changes somewhere
between. The times() function provides more useful information.


Steve Reid stever@qnx.com
TechPubs (Technical Publications)
QNX Software Systems

“Steve Reid” <stever@qnx.com> wrote in message
news:ae4tpr$4av$1@nntp.qnx.com

Ron Cococcia <> ude.ipr.sc@rcococ.nospam> > wrote:
: Hi,
: I was looking at a problem that was recently discovered with a program I
: wrote. It has to do with when someone adjusts the system clock (using
date
: and rtc), the clock() function gets confused. I checked the return
value of
: clock() and it was returning -1.

: I vaguely remember some kind of problem related to clock() when the
system
: time gets changed, and what it thinks the time really is. Is the
clock()
: getting confused because it’s start time compared to the current time is
too
: long? What might I do to prevent it from doing so if it is?

Steve McPolin once described clock() as brain-dead. Here’s a note that
was added to the docs at some point since they were released:

The clock() function simply returns the difference between the
current time and the time the program started, so it gives
incorrect results if the system time changes somewhere
between. The times() function provides more useful information.

As i can see from WATCOM C help clock() “return the number of clock ticks of
processor time used by the program”. So is it related to the astronomical
time of system which can be of course changed ? I thought that it’s just a
difference between internal timer’s counter values for current counter value
and value when program was started.

// wbr