Names in time.h C extension

[Markus Kuhn]

Thanks for the many comments that I have received on the modernized
<time.h> C API on

  http://www.cl.cam.ac.uk/~mgk25/c-time/

I'll try to respond to every comment individually, but there issue that
I'd like to address first separately: the names of the new elements.

Almost half of all comments that I received suggested that the
current namespace use of 

  struct xtime
  xtime_*()
  strfxtime()
  TIME_*

be changed into something else. I received numerous alternative
proposals, and the only common thing among them was that they were
almost all different. Most of the criticism seemed to have been just a
matter of taste and not based on technical superiority of the
alternative.

The individual proposals were:

Paul Eggert:
  xtime -> stime (short for "standard time", no rationale given)

Nathan Myers:
  xtime_format: "To plan or arrange in a specified form"
  xtime_compose: "To make or create by putting together parts or elements."
  xtime_resolve: "To separate (something) into constituent parts."

Ken Pizzini:
  timex

  "There is an old tradition of language design that the language and its
  libraries strongly avoid using identifiers starting with the letter 'x'
  --- a desperate application writer can then blithely prepenend an 'x' to
  all its first-choice identifiers and be safe."

John Hauser:

  xtime_sleep, xtime_pack, xtime_unpack

Jake Knoppers:

  timex

  "I would recommend using the term 'timex'. It is a invented term, a.k.a.
  coined term or neoligism, to which can be attached the apprpriate
  definition as well as a note at the end of such defintion of ' Formerly
  known as xtime'.

  'Time' as word is used with multiple meanings and its use can quickly
  become confusing and inadvertently may have unforeseen results. Having
  the x precede the _resolves the ambiguity resulting from the x after _ ."

Ken Pizzini:

  lists moment, instant, beat, clock, chronos, tiempo, heure, favours
  chronos

Antoine Leca:

  chronos is better than timex or xtime (without explanation)


Ok, here my reply:

How did I get to xtime? Well, the original type was called time_t and I
wanted to stay as close as possible to the traditional naming scheme of
the C API. So I removed the _t, because this is inappropriate for a
struct name. Now I had a collision with time(). My new type was an
"extended time", as it had extended range, extended resolution, and a leap
second extention, so for me 

  xtime for "extendted time type"

was a very obvious and nearby choice. While reviewing the comments, I
haven't found a convincing reason why any of the other name proposals
are better. Many of them are definitely worse. Some points I want to
mention are:

 - Since this type is both used for clock values and for time intervals,
   "time" seems to me a much more appropriate base term than anything
   based on "clock". The clock_* namespace is already reserved for POSIX.1.

 - The C API is completely based on the English language, introducing
   terms from other languages as Antoine proposed (chronos) would
   certainly break some tradition.

 - I have never run into the "old tradition" that Ken Pizzini mentioned
   of programming languages reserving x prefixes for application
   variables. Do you have a formal reference for this, especially for
   the C language. The thought that it is good practice to start all your
   application identifiers with "x" sounds quite bizarre to me. I am not
   too concerned about remote chances of name collisions with a small
   number of applications, as there are many simple tools out there to
   automatically replace identifiers in software.

 - the type can also be used for many things that can be described
   as non-standard times (TIME_MONOTONIC comes to mind), therefore
   I don't see at all the special appeal of stime (for "standard time").

 - I was surprised that suggestions that I had expected were not made:
   mkxtime would follow closer the traditional naming (as I did with
   strfxtime), and the traditional C API does not use underscores
   inside words (I was more influenced by POSIX.1b "tradition" here)
   anyway. Nathan Myers' proposal xtime_format instead of strfxtime
   goes even in the opposite direction, imitating more OO-style naming
   conventions instead of preserving the old style. I'd leave these
   ambitions to those who write the Python, Ada, Java, and C++
   bindings for these functions.

 - I used "delay" instead of "sleep" only because I feel that sleep
   implies that the process is suspended or that the processor is
   put into a sleep mode, while delay does not imply any such
   implementation detail. There is some tradition for sleep
   in the sleep and nanosleep POSIX system calls, but I
   felt that an OS-independent programming language should not
   imply implementation details such as sending the process into a
   sleep state. Therefore I considered the Ada and Turbo Pascal
   "delay" statements to be closer related and more appropriate
   as a source for the name.

 - xtime_pack and xtime_unpack has for me at least a very different
   connotation. For me, packing and unpacking sounds more like
   shuffling bits around into a more compact arrangement (analog to say
   Ada's "packed arrays"), and does not imply the application of
   time zone algorithms, etc. C programmers are familiar with mktime,
   so "make" seemed to me much more intuitive. The struct tm
   representation is referred to in the standard as a broken-down
   time format, therefore something based on breakup seemed to me the
   closest and most obvious choice for the name of the inverse
   function of "make". The existing practice of localtime() and
   gmtime() is not useful here, as the name there was completely based
   on the specific time zone.

Frankly, I don't care at all about the names, I am much more interested
in the functionality, but I am also not convinced why any of the
alternative proposals I have seen so far is better than what we have at
the moment. Therefore, I haven't changed anything here yet. The
committee is probably anyway going to rediscuss this issue, no matter
what we submit ... ;-)

Markus

-- 
Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK
email: mkuhn at acm.org,  home page: <http://www.cl.cam.ac.uk/~mgk25/>