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.

PR:
Obtained from:
Submitted by:
Reviewed by:


git-svn-id: http://svn.apache.org/repos/asf/apr/apr/trunk@63652 13f79535-47bb-0310-9956-ffa450edef68

1 files changed, 4 insertions, 3 deletions

diff --git a/STATUS b/STATUS
index 9ff1e8c78..53ec3f7d2 100644
--- a/STATUS
+++ b/STATUS
@@ -1,5 +1,5 @@
 APACHE PORTABLE RUNTIME (APR) LIBRARY STATUS:			-*-text-*-
-Last modified at [$Date: 2002/07/13 02:46:46 $]
+Last modified at [$Date: 2002/07/13 13:35:19 $]
 
 Release:
 
@@ -64,7 +64,7 @@ CURRENT VOTES:
 
       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 @@ CURRENT VOTES:
          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 @@ CURRENT VOTES:
                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)