There currently are four options listed in STATUS for changing the time representation. There are vetoes for two of them. The other are:
2) Renaming the function to get rid of apr_time_t vs time_t confusion, but keep it ambigious and make no contract with the user about the units represented. 3) Renaming the function to get rid of apr_time_t vs time_t confusion, and strongly identify the type as apr_busec_t or apr_butime_t, with an ongoing contract with users about the type's units. Based on all our discussions of the past few days, I believe these two options are identical in practice. If the new time type is an abstract type, the common operations on it will be: - Native C scalar + and - operations for time arithmetic (for performance and simplicity reasons) - Macros to extract seconds and microseconds And if it's a transparent type, the common operations will be: - Native C scalar + and - operations for time arithmetic - Macros to extract seconds and microseconds (to spare application programmers the complexity of doing the shifts themselves) I.e., no matter which option we use, I anticipate that the code surrounding these types will look exactly the same. The only major difference remaining seems to be the naming: apr_utime_t (and interval variants thereof) vs apr_time_busec_t (and interval variants thereof). Can we come to an agreement on one of these names to bring the issue to a close? Thanks, --Brian