Posts Tagged ‘time’
The ISO C standard specifies that
The clock function determines the processor time used.
It is clear that the result should be processor time instead of wall-clock time (real time).
It turns out that
clock() in Microsoft C does return the wall-clock time instead of processor time.
I do understand Microsoft probably were not intentionally trying to violate the standard. It is meaningless to talk about processor time in DOS (nor does DOS provide any mechanism to measure processor time, afaik), and many programs used
clock() to measure real time even if there were lots of system calls, disk accesses, etc. (which would make processor time significantly differ from real time in time-sharing systems). Probably Microsoft intended to maintain this “compatibility.” But is this really necessary? They could have corrected this either during the migration from single-task DOS to time-sharing Windows, or from 16-bit Windows 3 to 32-bit Windows 95/NT – just one more “incompatibility,” compared to other huge differences, not so important, was it?
The Unix time is going to be 1234567890 this Friday or Saturday, depending on your timezone. In UTC (GMT), the time is Fri Feb 13 23:31:30 2009. This is a time of celebration for geeks!
For most people in the Western Hemisphere, this time falls on a Friday the 13th. We have three Fridays the 13th this year…
For people in the Eastern Hemisphere, it falls on this year’s St. Valentine’s Day.
The Unix time, or POSIX time, equals the number of seconds elapsed since the ‘Unix epoch’ (Jan 1 00:00:00 1970 UTC), ignoring leap seconds. The type
time_t in all Unices and Unix-likes, and many non-Unix systems including Microsoft Windows, stores Unix time.
Certainly our systems will not have any timing problem this Friday the 13th. We’re really going to have problems at Tue Jan 19 03:14:08 2038, when the Unix time overflows 32-bit signed integer. Hopefully nobody will still be using 32-bit systems. If represented in 64-bit signed integer, Unix time won’t overflow in 292.5