> unlikely that somebody would actually wait for some moment of time by > looping and repeatedly testing the current time, as given in the > Rationale. I believe that this is exactly what "cron" does. At least, some forms of cron. The example given in the rationale, although admittedly skeletal, didn't seem to do anything to block execution, which seems odd, although on a system that doesn't support multitasking I suppose it's not too unreasonable. "cron" does a "sleep" or "alarm"/"pause" here. It can do that because it's running under UNIX, which means it also knows that "time_t" is a straightforward arithmetic type, and thus doesn't need the "mktime" jiggery-pokery that's in the ANSI C standard. If you're writing C programs that purport to be able to run on several different OSes, you probably don't want them to spin waiting for some time to arrive; you are better off throwing in #ifdefs or an OS-interface module and using the native OS facilities for blocking until some particular time or for some particular length of time. (If the ANSI C committee is trying to to make it possible to write programs like this to run in a "pure C" environment, without requiring any OS services, they're making a mistake.) Once you get to that point, you can use "time_t" as an integral type if you're writing for a UNIX/POSIX environment, or use whatever other native timing facilities other OSes provide.