...

. . .the big problem here is that code like the Rationale's

when = *localtime(now); when.tm_hour += 1; deadline = mktime(when);

printf("Loop will finish: %s\n", asctime(when)); while (difftime(time(0), deadline) > 0) whatever();

is *not* "a paradigm for continuing some loop for an hour." The code may continue for two hours (or not at all) if it is executed just before a daylight saving time transition.

How? deadline is a time_t (GMT) and so is time(0).

(I hope I don't end up with egg all over my face on this one!) First, assume that it's 1:30:00 a.m. on a "spring forward" day when we execute the when = *localtime(now); statement. We next do a when.tm_hour += 1; which sets when.tm_hour to 2. We then execute the deadline = mktime(when); statement to answer the question "At what elapsed time in seconds since 1970 will my wall clock read 2:30 a.m.?" Since mktime knows we're springing forward, it returns -1 as a way of saying "There is no such time today." This means that the test in the while (difftime(time(0), deadline) > 0) whatever(); line will *always* succeed--so "whatever" will never be called. (Side questions: does this say anything about whether time_t should be signed? Does it say anything about extra checking difftime should do?) Now assume that it's 1:30:00 a.m. (for the first time :-) on a "fall back" day when we execute the when = *localtime(now); statement. Again we when.tm_hour += 1; deadline = mktime(when); to learn when our local wall clock will read 2:30 a.m. But that won't be until two hours from "now", so the loop will run twice as long as we might expect. --ado