RE: [ActiveDir] Storing dates in AD

Tue, 29 Mar 2005 20:39:38 -0800

Title: Storing dates in AD
These are good arguments but I still put my money on int8. However my main coding is in c++ and it is trivial to handle the value and is immediately in a usable format. Initially it was a pain in the butt because it was new, but I expect more and more tools will become available to decode it.
 
One thing I really like about int8 over the other formats.... I want to add 100 days, 14 hours, 35 mins, 30 seconds, and 600ms to a current time. Convert that to 100 nanosecond intervals and simply add to an int8 and you have the new date and don't have to worry about leap days, hours, seconds, etc. You don't need any COM to do it, simple basic API calls. But that is me, I dislike COM with a passion, also ADSI, etc.
 
Of course, like JoeK says, if using vbscript or anything else with binary/interger handling it will be more interesting. Doing stuff from UNIX/perl and filetime is fairly easy as well, you throw an int8 through some basic math and use the ctime function. I have published the algorithm for converting it in perl several times both on this list and in the pubs.
 
I think the argument is similar to why use binary for SDs or SIDs or GUIDs, etc. GUIDs are especially special as you will find them as unicode strings and as binary packs. Whomever is responsible for that could use a good smack. Chase property sets / extended rights some time and you start hating AD a little.
 
 
  joe
 
 

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Tuesday, March 29, 2005 8:25 PM
To: [email protected]
Subject: RE: [ActiveDir] 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