Re: ldapsearch in OL 2

[Peter W <peterw@usa.net>]

On Fri, Aug 03, 2001 at 05:18:40PM +1000, Matthew Palmer wrote:
> On Fri, 3 Aug 2001, Warren Dale wrote:
> 
> > I have used a technique like this to get all of July:
> > 	
> > '(&(modifyTimestamp>=20010701000000Z)(modifyTimestamp<=20010731235959Z))' 
> > 
> > Useful?
> 
> Unfortunately, not.  I have other programs (written in C, linked against
> -lldap and using ldapsearch()) which expect memberUntil to be a 6-character
> string of the form YYYYmm.  Changing all of that would be a pain in the
> butt.

So use a generic integer match. That's what we're doing. We've got a few 
attributes in a custom schema for time values, and have opted to use the 
Unix standard seconds-since-epoc instead of the LDAP standard. The LDAP 
standard makes for a human-readable number, but there are other advantages 
to counting straight seconds (like time elapsed comparisons). Besides 
that, strftime() makes a friendlier representation of time_t values 
than the LDAP standard, very quickly and easily.

> I specifically structured the field so that it would be simple to do the
> search.  A numeric string ordering match would work perfectly, and I'm going
> to install 2.0.12 in the hope it will solve my woes.

Perfect.

As for the suggestion of "YYYY[mm[dd[HH[MM[SS]]]]][{Z|{+|-}HH[MM]}]" -- I
don't like it. time()/gmtime()/localtime()/strftime()/mktime() all provide
very good time functions as-is. I don't see much sense in OpenLDAP
violating the published standard to provide something that still won't be
as flexible as what C has had for years. If anything, I would suggest that
someone consider an IETF draft to make seconds-since-epoc (UTC) a valid
option for directories. It would be up to application code to decide the
precision of the stored value.

My less than $0.02,

-Peter