|
Yeah I guess it could be confusing. Personally, I say use
unicode case insensitive. I don't like the idea of case sensitive LDAP searching
at all. Just because you use a case insensitive string doesn't mean you can't
put in case sensitive info, for instance look at proxyAddresses. I think using
case insensitive makes it more flexible.
Probably it would be used for some legacy attributes where someone is
expecting the case sensitive functionality.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, March 30, 2005 11:42 PM To: [email protected] Subject: RE: [ActiveDir] Storing dates in AD That’s just the
thing. There are way too many string choices. You have general
string, teletex, printable, IA5 and Unicode. I basically don’t have any
idea when it would be more appropriate to use the ones besides Unicode.
Unicode is by far the most prevalent in my directory although teletex gets used
a fair amount. Printable and IA5 are pretty rare. General is never
used at all, so I assume it is only the schema for standards
compliance. I take your point about
case sensitive as that is sure to cause chaos with search filters. It
seems like mostly Exchange attributes that use the case sensitive
versions. Does someone have a
clear use case on when to use the non-unicode
syntaxes? Joe
K. From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of joe 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] 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. 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
