Hi,
I work on HPUX application and i had a query regarding the sleep & localtime system call in HPUX.
Here is the code that we have :

const uint32_t WAKE_INTERVAL_SEC(30*60);
while (true) {

// Find out what time it is
time(&currentTime);

// Thread to align wakeup with clock 30 minute i.e if it is currently 9:20 wakeup after 10 minutes,
// If it is currently 9:05, wake up after 25 minutes.
// Calculate remaining number of seconds in this half hour.
sleepTime = WAKE_INTERVAL_SEC - (currentTime % WAKE_INTERVAL_SEC);
while (1) {

sleep(sleepTime);

// Do regular work
tptr = localtime(&currentTime);

if (12 == tptr->tm_hour && tptr->tm_min <WAKE_INTERVAL_MIN)
{
// Noon work to be done
}
}

Expected Behaviour:
As refered in above code, we expect that every half an hour, some work to be done and if that time happens to be between 12 and 12:30am then we also do noon work.

Actual Behaviour:
Most of the time it works as expected. But some times, sleep seems to exit a few seconds before 12:30 and so the logic fails and does the noon work. Ideally i would expect that noon work condition to fail, since thread has woke up at 12:30 and hence it cannot satisify noon work condition. ( Trace in syslog indicates that regular work has started at 12:30, but logging itself would have taken some time and i suspect sleep could have woken up early)

Question:
- Can sleep wake up before the schedule time ( other than SIGALRM) ? Are there any other conditions where sleep could wake up before scheduled time?
- Can localtime used for comparison return wrong time ?
- Is it possible that there are some time adjustments done internally(may be for internal clock drifting etc) which results in sleep waking up a second earlier than expected or local time doing some kind of adjustment for some reason?

Any inputs in this regards are appreciated.

Thanks & Regards,
nsv

I'd make a point of printing out the relevant values at each step just to check what's really going on, instead of assuming anything.
iirc, the sleep() fn is usually written to complete at the 'top' of the second ie it should sleep for at least <asked_for_secs>, but may sleep for longer, particularly if processor is busy.
http://www.opengroup.org/onlinepubs/...ons/sleep.html