|
What that google doesn’t tell you is
that NT got it because Dave Cutler used it in his other operating system, VMS. It
probably has it’s origins even before VMS though I’d have to check
to be sure. We ex-Digits (a.k.a. DECcies oddly enough) have been using 64 bit
integers for time for years. The 100 nanosecond interval is referred to as a “clunk”
in VMS internals documentation. Wook From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Isenhour, Joseph 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 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 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 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 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
|
Title: Storing dates in AD
