I can find all files and file size, date, and minute correctly, but I
just don't see why the hour is always wrong for all files.
My codes is show below for your ref. Could anyone please point out
the problem for me?
TIA
Rio
---
Private Declare Function FileTimeToSystemTime Lib "kernel32"
(lpFileTime As FILETIME, lpSystemTime As SYSTEMTIME) As Long
Private Declare Function FindFirstFile Lib "kernel32.dll" Alias
"FindFirstFileA" (ByVal lpFileName As String, lpFindFileData As
WIN32_FIND_DATA) As Long
Private Type FILETIME
dwLowDateTime As Long
dwHighDateTime As Long
End Type
Private Type SYSTEMTIME
wYear As Integer
wMonth As Integer
wDayOfWeek As Integer
wDay As Integer
wHour As Integer
wMinute As Integer
wSecond As Integer
wMilliseconds As Integer
End Type
Private Type WIN32_FIND_DATA
dwFileAttributes As Long
ftCreationTime As FILETIME
ftLastAccessTime As FILETIME
ftLastWriteTime As FILETIME
nFileSizeHigh As Long
nFileSizeLow As Long
dwReserved0 As Long
dwReserved1 As Long
cFileName As String * 260
cAlternate As String * 14
End Type
Sub SearchFile()
Dim hsearch As Long, lngRet As Long, sFileNm As String
Dim lpFileWFD As WIN32_FIND_DATA
Dim lpSystem As SYSTEMTIME
hsearch = FindFirstFile("c:\abc.exe", lpFileWFD)
lngRet = FileTimeToSystemTime(lpFileWFD.ftLastWriteTime, lpSystem)
sFileNm = Left(lpFileWFD.cFileName, InStr(lpFileWFD.cFileName,
vbNullChar) - 1)
Debug.Print sFileNm, lpSystem.wHour, lpSystem.wMinute
End Sub
It's not a problem it's all correct, the question is that the
WIN32_FIND_DATA members with UDT FILETIME are expressed in UCT
(Coordinated Universal Time), That means that the diference in the
hours that I have on my locale it's diferent from your's.
Now your question is OK but how can I find the diference between the
UCT and local time, that is a whole problem by itself.
I never had to do this before so I'm really playing along the road.
First thing to remember UTC = LocalTime+bias => LocalTime = UTC-Bias
Second bias change taking in consideration the DayLightSavings Date
Third So We can make proper handling of dates is better to convert
them to vbDate format.
So After some testing I've come up with this air code, So allow many
error, a lot of stuff that was no considered. The whole thing about
TIme Zones and locales can have a infinitude of problems, maybe
someone can say where did I go wrong <g>
Option Compare Database
Option Explicit
Type TIME_ZONE_INFORMATION
Bias As Long
StandardName(31) As Integer
StandardDate As SYSTEMTIME
StandardBias As Long
DaylightName(31) As Integer
DaylightDate As SYSTEMTIME
DaylightBias As Long
End Type
Private Declare Function apiFileTimeToSystemTime Lib "kernel32" _
Alias "FileTimeToSystemTime" _
(lpFileTime As FILETIME, _
lpSystemTime As SYSTEMTIME) As Long
Private Declare Function apiFindFirstFile Lib "kernel32.dll" _
Alias "FindFirstFileA" _
(ByVal lpFileName As String, _
lpFindFileData As WIN32_FIND_DATA) As Long
Private Declare Function apiGetTimeZoneInformation Lib "kernel32" _
Alias "GetTimeZoneInformation" _
(lpTimeZoneInformation As TIME_ZONE_INFORMATION) As Long
Sub SearchFile()
Dim hsearch As Long
Dim lngRet As Long
Dim sFileNm As String
Dim lpFileWFD As WIN32_FIND_DATA
Dim lpSystem As SYSTEMTIME
Dim lpTZI As TIME_ZONE_INFORMATION
Dim dtmFileDateUCT As Date
Dim dtmFileDate As Date
Dim lngMinutesToAdd As Long
hsearch = apiFindFirstFile("c:\Command.com", lpFileWFD)
lngRet = apiFileTimeToSystemTime(lpFileWFD.ftLastWriteTime,
lpSystem)
sFileNm = Left(lpFileWFD.cFileName, InStr(lpFileWFD.cFileName,
vbNullChar) - 1)
'get Time Zone Information
lngRet = apiGetTimeZoneInformation(lpTZI)
dtmFileDateUCT = DateFromST(lpSystem)
If DateFromST(lpTZI.DaylightDate) <= Now Then
'daylight now
lngMinutesToAdd = lpTZI.DaylightBias * -1
Else
'normal bias
lngMinutesToAdd = lpTZI.Bias * -1
End If
dtmFileDate = DateAdd("n", lngMinutesToAdd, dtmFileDateUCT)
Debug.Print "---Final Result---"
Debug.Print "File Name: " & sFileNm
Debug.Print "File Date UCT: " & Format(dtmFileDateUCT, "c")
Debug.Print "File Date : " & Format(dtmFileDate, "c")
Debug.Print "---Time Zone Info---"
Debug.Print Format(DateFromST(lpTZI.DaylightDate), "c")
Debug.Print lngMinutesToAdd
End Sub
Function DateFromST(dtmIN As SYSTEMTIME) As Date
'More work needed I'm sure specially when the wYear = 0
Dim intYear As Integer
With dtmIN
If .wYear = 0 Then
'If no Year is specified then it's the current year
intYear = Year(Date)
Else
intYear = .wYear
End If
DateFromST = DateSerial(intYear, .wMonth, .wDay) + _
TimeSerial(.wHour, .wMinute, .wSecond)
End With
End Function
On Thu, 19 Aug 1999 10:38:55 GMT, LeoG...@email.com (Leo Graham)
wrote:
Hi Rio,
I think I just posted some code to your other msg, but just in case,
check the thread titled "Re: FileSearch object - .FoundFiles.Item
causing runtime error 70".
basically, the time you're returning doesn't account for UTC Bias.
Since UTC = LocalTime+Bias, you need to compute the offset as well...
Short function like
Private Function fGetTimeBias() As Long
' Returns Local-UTC Bias in minutes
Dim lpTZI As TIME_ZONE_INFORMATION
Dim lngRet As Long, lngOut As Long
lngRet = apiGetTimeZoneInformation(lpTZI)
Select Case lngRet
Case TIME_ZONE_ID_INVALID:
'Error
lngOut = 0
Case TIME_ZONE_ID_UNKNOWN:
'cannot determine
lngOut = 0
Case Else:
lngOut = lpTZI.Bias + lpTZI.DaylightBias
End Select
fGetTimeBias = lngOut
End Function
and then the correct time will be
' format the time according the system settings
strTime = Space$(255)
lngLen = apiGetTimeFormat(LOCALE_SYSTEM_DEFAULT, _
LOCALE_NOUSEROVERRIDE, _
lpSystem, _
0, _
strTime, _
Len(strTime) - 1)
strTime = Left$(strTime, lngLen - 1)
' format the date according to the system settings
strDate = Space$(255)
lngLen = apiGetDateFormat(LOCALE_SYSTEM_DEFAULT, _
LOCALE_NOUSEROVERRIDE, _
lpSystem, _
0, _
strDate, _
Len(strDate) - 1)
strDate = Left$(strDate, lngLen - 1)
fGetFileTime = strDate & Chr$(vbKeySpace) & strTime
' UTC = local time + bias
fGetFileTime = CStr(DateAdd("n", -fGetTimeBias(), CDate
(fGetFileTime)))
-- Dev
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
I as soo distrated by your question that I did forgot to tell you this:
I don't known why are you using the API, maybe you need or want, but that
information you can get it using just a plain old function, no
TimeZoneProblems here <g>
?FileDateTime("c:\command.com")
11-05-98 20:01:00
Pedro Gil
My reason of using API to search for files is due to the problematic
FileSearch object which produces erratic and unexpected results in my
findings. So I then use the other way to find files, but it produces
another problem of time zone to me. Since I've use FindFirstFile to
find out the file, if I use FileDateTime again to get the related
info, I understand that FileDateTime needs to search once again for
the file in the harddisk before getting the datetime, which takes
additional time in file searching. Since I also use FindNextFile in
my code, there'll be many files needed to be searched doubly.
That's my point. (Please advice me if I'm wrong.)
Rio
After reading the msg from Dev, I went to look to the other thread,
and yes you are correct, IMHO if you allready have to use the API to
Find File then stick with it to get the rest of the information.
I don't known if the FileDateTime will do another search.
With mine and specially Dev post I would say that you don't have a
TimeZone Problem.
Pedro Gil
Thanks for your code. I still need time to absorb. :)
Rio
On Thu, 19 Aug 1999 22:14:41 GMT, Dev Ashish <das...@hotmail.com>
wrote: