This is a very good argument for using 2.5.5.11. I've changed my mind.
 
-gil

________________________________

From: [EMAIL PROTECTED] on behalf of [EMAIL PROTECTED]
Sent: Tue 3/29/2005 2:40 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.

 

________________________________

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

 

Actually I just googled this and found something interesting that I didn't know:

Windows NT uses a 64-bit integer to track time. However, it uses 100 
nanoseconds as its increment and the beginning of time is January 1, 1601, so 
NT suffers from the Year 2184 problem. 

I don't think we'll be on the same system in 2,184, but I don't want to be 
short sighted :)  Does Microsoft still use a 64-bit integer?

That's a good point Al, the date is not going to be compared to the other date 
types in AD so I suppose it really doesn't matter.  I may go with the NT date 
just to be consistent.

 

 

________________________________

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

I think it still depends on how you intend to use the data.

 

For example, if you're going to pull other information of similar type (maybe 
pwdLastSet?) it would make sense to use the same format. 

 

Al

 

________________________________

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

We are going to be modifying the field programmatically so from what Gil said 
it sounds like the large integer method is appropriate.  As a follow up 
question, do you think I should use nano seconds from the Jan 2, 1970 (UNIX 
style) or January 1, 1601 (The date used by pwdLastSet)?

 

________________________________

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe
Sent: Monday, March 28, 2005 5:33 PM
To: [email protected]
Subject: RE: [ActiveDir] Storing dates in AD

Bingo, how is the data going to be used? I definitely agree, don't come up with 
your own format unless you have some amazing scheme that blows all of the other 
formats out of the water that makes it the best thing to do. Not saying you 
aren't going to come up with something amazing but I would guess the odds are 
against you. Anything you put into the directory, keep it in UTC. Less 
confusion that way.

 

  joe

 

________________________________

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gil Kirkpatrick
Sent: Monday, March 28, 2005 3:44 PM
To: [email protected]
Subject: RE: [ActiveDir] Storing dates in AD

Depends on the domain of the date values, and how they are used. If the dates 
will be passed along to other X.500/LDAP type directories, you probably should 
use the Generalized Time syntax (2.5.5.11). If the dates are manipulated 
programmatically, use the long integer representation. Its pretty trivial to 
manipulate it as a date in your code. I'd avoid using a string representation 
unless your code requires a funny string format or unless it requires unusual 
date values like "today", "yesterday", or "when hell freezes over" (we use the 
latter for setting development dates for certain silly feature requests in our 
products :)

 

-gil

 

________________________________

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Isenhour, Joseph
Sent: Monday, March 28, 2005 1:15 PM
To: [email protected]
Subject: [ActiveDir] Storing dates in AD

I'm looking for some opinions on a schema extension.  I need to store a date 
type in AD.  I figure I have several options.

Store it as a long integer.  To determine the date the consumer will need to 
count the nano seconds from a certain date (the way that pwdLastSet works)

Store it as a date type (which I've never used, and looking at the current 
schema it appears that most people do not choose this option).

Store it as a unicode string and come up with a format like:  YYYYMMDD[ss][ss] 

Does anyone have an opinion on how this should be done? 

Thanks 

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.

<<winmail.dat>>

Reply via email to