Title: Storing dates in AD

In an LDAP filter, generalized time and UTC time look like this:

 

(yourTimeAttribute= YYYYMMDDHHMMSS.0Z)

 

As such, they are pretty easy to spit out with code and are also human readable.

 

LDP and ADSI Edit will also show these in a friendly format.

 

With integer8, they look like this:

 

(yourTimeAttribute=125655822921406250)

 

Those are not human readable and require code to interpret.  Additionally, the IADsLargeInteger thing is a huge PITA in my book and is worth avoiding for that reason alone if you need to deal with VBScript.

 

In script, generalized time and UTC time are converted by ADSI to and from normal COM variant date times, so in VBS they’ll show up as normal date values.  No special processing is required.

 

Joe K.

 


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Isenhour, Joseph
Sent: Tuesday, March 29, 2005 5:24 PM
To: [email protected]
Subject: RE: [ActiveDir] Storing dates in AD

 

Joe,

 

You make a good point.  What would an LDAP >= filter look like using this data type?  I'm familiar with VB and VBScript.  So are you saying that I can simply create a date type in script and use ADSI for example and set my variable to the AD attribute and it will convert automatically?

 


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Tuesday, March 29, 2005 2:41 PM
To: [email protected]
Subject: RE: [ActiveDir] Storing dates in AD

I still don’t think you should use Integer8/FILETIME format to store your date unless you absolutely need to.  I think 2.5.5.11 OM 23 or 24 is the way to go.  Depending on your API I think you will likely find them to be a better impedance match.

 

The big kicker is if you ever have to use VBScript to do this.  VBScript sucks at dealing with long integers but happily marshals LDAP 2.5.5.11 to variant datetime and back.

 

Plus, you’ll get some nicer fidelity in other tools such as ldp and ADSI Edit.  Integer8 will just be an opaque number that you need code to interpret.

 

2.5.5.11 values sort and index just fine and allow >= and <= comparisons, so I can’t think of a real compelling reason to use Integer8 unless your code happens to already rely on that.  It sounds like it doesn’t.

 

Joe K.

This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.

Reply via email to