Wed Feb 11 20:35:58 UTC 1987
> unlikely that somebody would actually wait for some moment of time by
> looping and repeatedly testing the current time, as given in the
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
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.
More information about the tz