Profile Stuff..

[Gandalf]

And what about the Created Account date, it shows: "29475313 2842110102" What i have to do to show me the normal date?

[Newby]

Create a sub to parse it.

[UserLoser.]

It's a filetime, one part is lowdatetime, other is highdate time... Look into the SYSTEMTIME and FILETIME structs, along with FileTimeToSystemTime()

[Gandalf]

Whats wrong with this:
Private Function ReturnDHMS(iSec1 As Single) As String
   
   Dim iMin As Single
   Dim iHrs As Single
   Dim iDay As Single
   Dim iSec As Single
   
   iSec = iSec1
   
   iHrs = (iMin \ 60)
   iMin = (iSec \ 60)
   iSec = (iSec Mod 60)
   
   If iHrs >= 24 Then
       iDay = iHrs \ 24
       iHrs = iHrs Mod 24
   End If
   
   ReturnDHMS = "Day:" & Str(iDay) & "  Hrs:" & Str(iHrs) & "  Min: " & Str(iMin) & "  Sec: " & Str(iSec)
   
End Function

[Lenny]

Well the other profile keys are sent as unsigned dwords in the form of Filetimes...not seconds


Bnet sends you it in
HIGHdate
LOWdate
order.

You need to also convert it using FileTimeToLocalFileTime() before using FileTimeToSystemTime()

[UserLoser.]

You need to also convert it using FileTimeToLocalFileTime() before using FileTimeToSystemTime()

That's not true

[Lenny]

Well I assume most people would want the local time they created the account, not the time a bnet server recorded it.....

[Spht]

Well I assume most people would want the local time they created the account, not the time a bnet server recorded it.....

If you sent Battle.net proper location information, it'll return the time in your timezone.

[Eric]

If you sent Battle.net proper location information, it'll return the time in your timezone.

That's not true for profile keys.

[UserLoser.]

TimeZone is either sent in the 7th DWORD of 0x50 (SID_AUTH_INFO), or the 5th DWORD of 0x12 (SID_LOCALEINFO)...

Correct information to send is the Bias + StandardBias from TIME_ZONE_INFORMATION struct, which can be retrieved using GetTimeZoneInformation()

Note: 0x12 is only used by either W2BN/JSTR/DRTL/DSHR, while 0x50 can be used for any product

[Spht]

If you sent Battle.net proper location information, it'll return the time in your timezone.

That's not true for profile keys.

Probably because profiles contain no time information? I'm referring to the system times stored on the Battle.net server for things like last game, last logon, etcetera.

[Eric]

From BnetDocs:

SID_READUSERDATA (0x26)
Packet ID: 0x26
Direction: Server -> Client (Received)
Format:
Help (DWORD)       Number of accounts
(DWORD)       Number of keys
(DWORD)       Request ID
(STRING[])    Requested Key Values

I feel the term "profile keys" fits quite well with the information you'd put into the string array of a user data request, if you see it differently, so be it.

Aside from that, when the information returned from 0x26 is in FileTime format, the FileTime is sent in Battle.net Time, not Local Time, no matter if the information you send in 0x50 is accurate or not.

Now, I'm done arguing about something that I know is right.

[Spht]

From BnetDocs:

SID_READUSERDATA (0x26)
Packet ID: 0x26
Direction: Server -> Client (Received)
Format:
Help (DWORD)       Number of accounts
(DWORD)       Number of keys
(DWORD)       Request ID
(STRING[])    Requested Key Values

I feel the term "profile keys" fits quite well with the information you'd put into the string array of a user data request, if you see it differently, so be it.

Aside from that, when the information returned from 0x26 is in FileTime format, the FileTime is sent in Battle.net Time, not Local Time, no matter if the information you send in 0x50 is accurate or not.

Now, I'm done arguing about something that I know is right.

Yes, I was referring to whoever said using FileTimeToLocalFileTime to convert it to your local time would be a valid solution.

[Eric]

If you sent Battle.net proper location information, it'll return the time in your timezone.

Yes, I was referring to whoever said using FileTimeToLocalFileTime to convert it to your local time would be a valid solution.

It is, but after that you'd still have to convert it to SystemTime to get the "real" date/time.

[Spht]

Yes, I was referring to whoever said using FileTimeToLocalFileTime to convert it to your local time would be a valid solution.

It is, but after that you'd still have to convert it to SystemTime to get the "real" date/time.

Assuming you want the time as a SYSTEMTIME structure, which isn't a requirement.