|
I am not sure it is limited to SAM, I think it may be when
it is likely they will be doing comparisons and modifying by a delta or finding
a delta. I could be wrong though.
What kind of conversation on strings are you looking for?
Generally use case insensitive unicode strings. If you use case sensitive get
ready to hear Windows Admins/Devs screaming because they don't know what is
happening.
joe
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, March 30, 2005 12:29 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Storing dates in AD My observation is that
MS uses integer8 when they are representing OS data that is manipulated as
FILETIME in normal Windows routines. I’m guessing that the SAM functions
use FILETIME internally, so it was natural to store them natively in AD this way
for compatibility. They use the LDAP time
formats when they are creating attributes that try to match existing LDAP
standards. Then there is the rest
of the time in between where I have no idea what made them decide to go one way
or the other. J I would love to
hear how their schema designers actually make these decisions. Maybe we
can get someone from the product team to comment (hint hint).
I’d also love to hear a
good discussion on which string syntax to use in which situation. Good
schema design takes some real knowledge that isn’t that easy to come by.
It is a lot harder to dive into than SQL for
example. Joe
K. From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Isenhour,
Joseph I really appreciate all
of the opinions on this. I've been playing around with these different
types in my sandbox. I've used VBS, C#, VB.NET, and pretty much all of the
languages that we hack programmers use :) The generalized date
type worked really well. From looking at the base AD schema it appears
that there is a difference of opinion among the MS programmers because the use
of these different types is roughly the same. From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of joe If you use large int
use filetime - Number 100 nanosecond intervals from jan 1, 1601. There
is some docs (in fact I think there are some typos in Gil's book) that mention
the 1970 date but I am not aware of anything in AD that uses anything but
filetime. http://msdn.microsoft.com/library/default.asp?url=""> If you use int8
and don't use filetime, you will have some developer hunt you down most likely
later on because their generic function that works on all other int8's
doesn't work on yours.
joe From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Isenhour,
Joseph 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 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 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 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. |
Title: Storing dates in AD
- RE: [ActiveDir] Storing dates in AD joe
- RE: [ActiveDir] Storing dates in AD joseph.e.kaplan
- RE: [ActiveDir] Storing dates in AD Lee, Wook
