jim 2002/07/13 06:35:20
Modified: . STATUS
Log:
Cast a vote, though I have on purpose avoiding chiming in during
the debate. In general, however, the need for second and microsecond
resolution seems pretty clear to me, as well as the need for as
much scalar ops as possible.
Revision Changes Path
1.164 +4 -3 apr/STATUS
Index: STATUS
===================================================================
RCS file: /home/cvs/apr/STATUS,v
retrieving revision 1.163
retrieving revision 1.164
diff -u -r1.163 -r1.164
--- STATUS 13 Jul 2002 02:46:46 -0000 1.163
+++ STATUS 13 Jul 2002 13:35:19 -0000 1.164
@@ -64,7 +64,7 @@
1) Keeping the existing apr_time_t names, in spite of confusion
with ANSI/C99 time_t's units, and prior decimal usec definition.
- +1: rbb, jerenkrantz, striker, dreid
+ +1: rbb, jerenkrantz, striker, dreid, jim
+0: wrowe [apr_types don't promise to map to C99/ANSI units]
+0: brianp
-1: aaron [veto for reusing the apr_time_t identifier for a new use]
@@ -80,6 +80,7 @@
units represented. Needs a better suggestion than apr_timeval_t.
+1: aaron, brianp, ianh,
fielding [prefers apr_utime_t and apr_utimediff_t (64bit)]
+ +0.5: jim
-0: jerenkrantz, striker, dreid
-0.5: rbb
wrowe [prefers apr_utime_t and apr_uspan_t where u==undefined]
@@ -91,7 +92,7 @@
brianp, [can live with apr_time_busec_t and apr_span_busec_t]
fielding [me too]
-0: striker, jerenkrantz
- -0.5: rbb, ianh, dreid
+ -0.5: rbb, ianh, dreid, jim
4) Using time_t and struct timeval/tm
+1: fielding (if apr_time is not an ADT)
