Re: slap_timestamp with microsecond granularity?

[Howard Chu <hyc@symas.com>]

Since you're talking about changes to actual OpenLDAP code, this discussion 
belongs in openldap-devel, not openldap-technical.

Paul B. Henson wrote:
> Reviewing current time handling code, while lutil_parsetime understands
> and can parse a generalized time that includes fractions of a second,
> there doesn't seem to be any code that can generate a generalized time
> string including fractions of a second, in particular to microsecond
> resolution (to match a struct timeval time)?

Clearly such code must exist in the source tree, since entryCSNs use 
microsecond resolution.
> I'd like to enhance the current password policy module to use
> microsecond resolution for the pwdFailureTime attribute, as the current
> 1 second resolution makes it less than ideal for account lockouts.
> Currently, it is using slap_timestamp to generate the generalized time
> to store, which only provides a generalized time with 1 second
> granularity. On initial review, it looks like simply storing a generalized
> time with microsecond resolution in the pwdFailureTime attribute is all
> that is required to enhance the ppolicy module for better account
> lockout support, because as previously mentioned lutil_parsetime already
> understands and can parse fractional seconds. I don't see any other code
> that would need to be modified so far.
>
> The question is how to generate the needed format? One option would be
> to enhance one way or another the existing generic support, perhaps
> adding a slap_timestamp_usec function? Another would be to just add a
> call to gettimeofday() next to the current call to time() in the ppolicy
> code, generate the generalized time string with slap_timestamp, and then
> mash the fractional seconds into it.

gettimeofday() only exists on POSIX systems; if you're adding a generic 
slap_xxx function it has to be portable across Windows and other OSs too.

> Ideally I'd like to get this enhancement to ppolicy accepted into the
> code base, so I'd appreciate some feedback as to what implementation
> would be preferred for this.
>
> Thanks...


--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/