Title: RE: [ActiveDir] Converting Active Directory 64 Bit Time Values into Date Strings with Perl and general process you can use for other languages

I have one in vb.net if anyone is interested.

Carlos Magalhaes - Active directory programming http://groups.yahoo.com/group/adsianddirectoryservices

-----Original Message-----
From: Dean Wells [mailto:[EMAIL PROTECTED]]
Sent: Saturday, September 06, 2003 2:12 AM
To: AD mailing list (Send)
Subject: RE: [ActiveDir] Converting Active Directory 64 Bit Time Values into Date Strings with Perl and general process you can use for other languages

In addition to Joe's insight, both Windows XP and Server 2003 (but not 2000)
include a command line tool that produces the same end result -

C:\>w32tm /ntte 127000000000000000
146990 17:46:40.0000000 - 6/13/2003 1:46:40 PM (local time)

In addition (and as recently referenced in the public newsgroups), I wrote a
script (no non-native or 3rd party additions required) some time back that
can be glued into AD U&C to provide a simple context sensitive query to
discover (for example) all accounts that will expire prior to a supplied
date.

Thanks for the Perl snippet!

Dean

--
Dean Wells
MSEtechnology
* Tel: +1 (954) 501-4307
* Email: [EMAIL PROTECTED]
http://msetechnology.com



-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Joe
Sent: Friday, September 05, 2003 7:53 PM
To: [EMAIL PROTECTED]
Subject: [ActiveDir] Converting Active Directory 64 Bit Time Values into
Date Strings with Perl and general process you can use for other
languages


I have been asked multiple times for this info in newsgroups and emails
to my joeware email and again at work yesterday so I wrote this up.
Thought I would share with the group here in case anyone cares.

---

First off the 64 bit Integer Time Values (Called Integer8) represents
the number of 100 nanosecond intervals between the time stamp and
January 1, 1601. Don't ask me why, this is just what it is, I am not
even going to attempt to explain it other than I wasn't around prior to
1969 so what happened with computers in 1601 is far outside my personal
scope of really caring. In fact I am not sure anything even existed then
because I didn't, it is up for debate.

1. Remove last 7 characters - Usually this will be all zeros but it may
be actual digits if you care to get down to 100 nanosecond accuracy, you
can figure it out.

2. Subtract off 11644473600

You are now at a value that is the number of seconds since since January
1, 1970. Again I will not explain even though I was around then. I still
wasn't at the point that I worried about time stamps on computers, I was
still flabbergasted that man had walked on the moon 6 short months
previously...

This value was targeted because there are functions out there that use
that format for time already and you can leverage them to convert to a
friendly time/date stamp such as ctime or localtime or gmtime.

So how to do this in perl??

Here is a quick perl script:

___t64.pl___
$t64=shift;
$t64=~s/(.+).{7,7}/\1/;
$t64-=11644473600;
($sec, $min, $hour, $mday, $mon, $year, $wday, $ydat,
$isdst)=localtime($t64); $mon++; $year+=1900;
print "$mon/$mday/$year - $hour:$min:$sec  DST - $isdst\n";


When you run it it will produce something like:

C:\Temp>t64 127069827243689315
9/2/2003 - 9:25:24  DST - 1


Use as you wish.

For other cool methods to play with those time fields in Perl check out
Robbie Allen's upcoming book - Active Directory Cookbook. :o)


   joe





List info   : http://www.activedir.org/mail_list.htm
List FAQ    : http://www.activedir.org/list_faq.htm
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/



List info   : http://www.activedir.org/mail_list.htm
List FAQ    : http://www.activedir.org/list_faq.htm
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/

-------------------------------------------------------------
This email and any files transmitted are
confidential and intended solely for the
use of the individual or entity to which
they are addressed, whose privacy
should be respected.  Any views or
opinions are solely those of the author
and do not necessarily represent those
of the Trencor Group, or any of its
representatives, unless specifically
stated.  

Email transmission cannot be guaranteed
to be secure, error free or without virus
contamination.  The sender therefore
accepts no liability for any errors or
omissions in the contents of this message,
nor for any virus infection that might result
from opening this message.  Trencor is not
responsible in the event of any third party
interception of this email.   

If you have received this email in error please notify
[EMAIL PROTECTED]   For more information about
Trencor, visit www.trencor.net <http://www.trencor.net>

Reply via email to