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/>