>>Thanks for your reply Joe,
>>
>>Perhaps you can provide an example when you return from Philly. I looked at the help, and played with some code, but I don't see how I can make this work to convert a signed 64-bit integer to a datetime format.
>>
>>If you can provide any additional information I will be very grateful!
>>
>>Thanks,
>>- Kile
>>
>>>Look at TimeOfDay.xxx
>>>
>>>Gotta run, I am of to Philly. I will not be able to chime in before then.
>>>
>>>HTH,
>>>
>>>
>>>>Scanning the .NET help files, help for the Convert.ToDateTime Method (Int64) returns the following information:
>>>>
>>>>"This conversion is not supported..."
>>>>
>>>>What's up with this?
>>>>
>>>>Specifically, I am writing a VB.NET routine that is querying Active Directory. First of all, I can't understand why the following AD fields are of data type Long:
>>>>    badpasswordTime
>>>>    pwdlastset
>>>>    usncreated
>>>>    accountexpires
>>>>    lastlogoff
>>>>    usnchanged
>>>>
>>>>...while the following fields are of data type Date:
>>>>    whencreated
>>>>    whenchanged
>>>>
>>>>They should all be date-time values shouldn't they?
>>>>
>>>>It wouldn't be a problem if the routine mentioned in the subject of this email were available, but it's not. How would one go about converting one of these 64-bit signed integer values to its equivalent DateTime format value (using VB.NET)?
>>>>
>>>>Thanks in advance!
>
>Hi Kile, I spent some time on this last night. Create a form with 3 list boxes [lstTime,lstDiff,lstDate] and a timer [tmrSeconds]. Set the timer interval to (1 sec)1000. I lined the list boxes up so I could get a good visual representation. I have included the code below. No imports or impliments are needed. I included the progression of my experimentation for you to see. It looks like d.FromFileTimeUtc(lngticks).AddYears(-1600) is the answer. I am sure someone here can solve the extra 1600 years issue. I tried with both date and datetime
> anyway here is the code. Work with it a little and let me know how it goes.
>

>    Private Sub tmrSeconds_Tick(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles tmrSeconds.Tick
>        Dim dt As DateTime = DateTime.Now
>        Dim d As Date = Now
>
>        If lstTime.Items.Count < 25 Then
>            Dim lngticks As Long = dt.Ticks
>            ' lstDate.Items.Add(dt.TimeOfDay.FromTicks(lngticks)) ' Poor formating
>            'lstDate.Items.Add(dt.FromFileTimeUtc(lngticks)) ' Why the year is 3603 I dont know.
>            'lstDate.Items.Add(d.FromFileTimeUtc(lngticks))   ' Why the year is 3603 here too, I dont know.
>            lstDate.Items.Add(d.FromFileTimeUtc(lngticks).AddYears(-1600)) ' this is definately a hack :(
>            lstTime.Items.Add(lngticks.ToString)
>            If lstTime.Items.Count > 1 Then
>                lstDiff.Items.Add(lstTime.Items.Item(lstTime.Items.Count - 2) - lstTime.Items.Item(lstTime.Items.Count - 1))
>            Else
>                lstDiff.Items.Add("Start")
>            End If
>        End If
>    End Sub
>

>
>HTH,

Hello Joe,

Sorry for the delay in responding - I do appreciate your response though. Your example is a good one, and not similar to any of the others I've seen on the web yet while researching this. However, it didn't do the trick for me because of what I think is a problem with the actual value (or data type?) that I'm starting with.

When scanning the resulting properties of an Active Directory SearchResult, one of the properties is "badpasswordtime", which VB typecasts as Long. I have read various conflicting information on the web, and have not yet been able to determine why this particular field is being stored as what VB thinks is a Long datatype, as opposed to a DateTime field (as there are other DateTime fields being returned in the very same SearchResult). In addition, even though this field is being cast as a Long, using it in any of the calculations I've seen so far that require a Long datatype, has yet to return a value that is even remotely close to what I would expect. So I'm wondering if VB is casting it as a Long value, when in fact it is something different...

Regarding your 1600 value above: It is definately not a hack. The number of ticks returned by the DateTime.Ticks method is the number of seconds (or in some cases, I've read that it's the number of 100 nanoseconds), since January 1, 1600. Of course I've also read that the starting date was 1601. And in yet another web article, as well as the adsi25.chm file (in the Microsoft Active Directory SDK), they state that the number of ticks is the number of seconds since January 1, 1970. Based on your test, it looks as if the 1-1-1600 date seems to be correct.

Because of the lack of consistent information I've found regarding this problem, I think I'm going to lay it to rest for now. Too many other projects that need to get done right now.

Thanks to all who took the time to respond!