ANSI C.

[Ray Butterworth]

  > gmtime(), like time(), ctime(), and localtime(), takes a
  > pointer to a time_t because that's what they already do.
  > These functions have been defined (in UNIX at least) for a
  > long time (no pun intended).

Simply because they have been around for a long time, doesn't
mean that they are the best way of doing things; and simply
because UNIX does it that way, doesn't mean that everyone else
should do it that way.  This is supposed to be a C standard,
not a make-the-world-look-like-UNIX standard.

I understand why they originally took pointers; but the need
is no longer there.  Now is the time to correct old mistakes
not propagate them.  A number of other functions are defined
by the standard that differ from the same functions on UNIX
(at least some versions of UNIX) and people are going to have
to make a number of changes to their code anyway.  It wouldn't
be that difficult for the standard to define these functions
with completely different names.  Systems that never had the
functions before can simply implement them as required, while
systems that have similar functions can either provide macros
or cover functions for mapping the one name and syntax into the
other until the general population gets used to the new names.
I know that for anything I write I already have a cover function
for ctime(), so that I can use ctime(time()) without having to
go through the bother of allocating a temporary variable that
I can take the address of.

  > difftime() accepts time_t arguments but returns a double.
  > Its result is expressed in SECONDS, whereas a time_t is not
  > necessarily expressed in seconds.  There is no portable way
  > to do simple arithmetic on general time_t values to produce
  > a time difference in seconds, hence difftime().

OK, this was my misreading of the standard.  The problem was that
it introduced CLK_TCK, clock_t, and time_t together, and it wasn't
obvious to me that CLK_TCK wasn't the conversion factor between the
two.  I wasn't the only one that made the same mistake.  There
really should be a note here that the meanings of the values of
time_t are implementation defined.

One of the biggest problems with the K&R C manual is the things
that it doesn't explicitly mention.  It often takes a student
of theological research to find the various hints and put them
together to make a definite rule.  Please don't make this new
standard work the same way.  i.e. don't leave the readers with
the idea that "if we didn't mention something, then you can do
what you want with it".  If something is implementation dependent
then the standard should explictly say so.  If something isn't
defined in the standard then we should assume that this was an
omission to be corrected in the future, not a deliberate loophole
that every implementor is free to interpret as he wishes.

  > Seems to me they put more thought
  > into it than some of their detractors..

True.  If I want to make a public fool of myself, that only
concerns me.  But if the standards are sloppy, then that is
everyone's business.  This is supposed to be a scientific
document giving precise rules; it isn't supposed to be the bible
for some religion of C-worshippers who will spend hours pondering
its mysteries and trying to interpret its hidden meanings.  Just
look at the articles that continually appear in this news group.
Far too many of them are discussions about what K&R really meant
when they said such-and-such, and proofs using quotations from
three different sections of the book to show what they really had
in mind.  Probably at least half of the articles in any year are
more or less identical with half the articles in any other year.
Wouldn't it be nice to have a document which explicitly tells us
how things are supposed to be instead of one which encourages such
time-wasting discussions?