6.20 vs 6.30 directoryEntryDate DST
Posted: Sat Jan 31, 2026 11:25 pm
I am finding that directoryEntryDate returns a different timestamp in 6.30 than 6.20. Is there a reason this might be possible?
Knowing I would get complaints without sample source code so I made up this one from the big program. I left the essence of the whole loop because that's just I how I am using it.
I'm sorry but I don't use the IDE editor. I used this batch file to compile it:
And these are the results filtered for one particular file:
So what Windows have to say about that file:
I'm only showing one file for brevity but it happens on many files.
I did see a viewtopic.php?p=637152&hilit=directoryEntryDate#p637152 but I don't think it applies here. And for reference, I'm United States Central Time which I think +6 UTC.
Any thoughts or ideas would be appreciated.
Dan
Addendum:
I added getFileDate ( ) to see if the outcome was different. Not sure I'm using that right but getFileDate returned the same time as directoryEntryDate ( )
Addendum:
Now I understand! I just changed my time to July 31, 2026 and now the times reported are the same.
Okay, the directory is reporting a different timestamp depending on (I'm guessing) whether Daylight Savings Time is in effect! Here is a condensed version from my command prompt showing the directory after I had changed the time.
Is 6.30 is handling DST differently ?
Addendum: I am working with two things.
First, I'm trying out getFileAttributesEx_ to get \ftLastWriteTime which is a quad UTC value. And then and using various posts in the past convert that to a PureBasic time using (PeekQ(@fileData\ftLastWriteTime) - #WIN32_FILE_TIME_OFFSET) / 10000000 I can use that for the definitive "has the timestamp changed"
Next, when I need to display it, I have to convert to local time using FileTimeToLocalFileTime_ ( ). I think I've got a function for that working.
Still, it's curious about PB 6.20 and 6.30, but I think I have a solution.
Knowing I would get complaints without sample source code so I made up this one from the big program. I left the essence of the whole loop because that's just I how I am using it.
Code: Select all
enableexplicit
declare justScanDirectory ( dirName.s )
global.i hFile
hFile = openFile ( #pb_any, "t_filedates.txt", #pb_file_append )
justScanDirectory ( "i:\library3" )
closeFile ( hFile )
procedure justScanDirectory ( dirName.s )
protected.i hEDir, fSize, fDate
protected.s fName
hEDir = examineDirectory ( #pb_any, dirName, "*.*" )
while nextDirectoryEntry ( hEDir )
fName = directoryEntryName ( hEDir )
fsize = directoryEntrySize ( hEDir )
fdate = directoryEntryDate ( hEDir, #pb_date_modified )
if fName = "." or fName = ".."
continue
endIf
select directoryEntryType ( hEDir )
case #pb_directoryEntry_File
writeStringN ( hFile, str ( #pb_compiler_version ) + " " + fName + " | " + str ( fsize ) + " | " + formatDate ( "%yyyy-%mm-%dd %hh:%ii:%ss", fdate ) + " | " + str ( fdate ) )
case #pb_directoryEntry_Directory
justScanDirectory ( dirName + "\" + fName )
endSelect
wend
endProcedure
Code: Select all
del t_filedates.txt
set c2=t_filedates
call "\progutil\pureBasic\pureBasic 6.20\compilers\pbCompiler.exe" "%c2%.pb" --output "%c2%.exe" --optimizer /XP --thread /dynamiccpu /ADMINISTRATOR
t_filedates
call "\progutil\pureBasic\pureBasic 6.30\compilers\pbCompiler.exe" "%c2%.pb" --output "%c2%.exe" --optimizer /XP --thread /dynamiccpu /ADMINISTRATOR
t_filedates
v t_filedates.txtCode: Select all
620 Instrumental.mp3 | 4262603 | 2013-08-11 16:37:44 | 1376239064
630 Instrumental.mp3 | 4262603 | 2013-08-11 17:37:44 | 1376242664Code: Select all
Sun 08-11-2013 04:37 pm 4,262,603 Instrumental.mp3I did see a viewtopic.php?p=637152&hilit=directoryEntryDate#p637152 but I don't think it applies here. And for reference, I'm United States Central Time which I think +6 UTC.
Any thoughts or ideas would be appreciated.
Dan
Addendum:
I added getFileDate ( ) to see if the outcome was different. Not sure I'm using that right but getFileDate returned the same time as directoryEntryDate ( )
Code: Select all
gdate = getFileDate ( dirName + "\" + fName, #pb_date_modified )Code: Select all
writeStringN ( hFile, prefix + fName + " | " + str ( fsize ) + " | directoryEntryDate > " + formatDate ( "%yyyy-%mm-%dd %hh:%ii:%ss", fdate ) + " | getFileDate > " + formatDate ( "%yyyy-%mm-%dd %hh:%ii:%ss", gdate ) )Addendum:
Now I understand! I just changed my time to July 31, 2026 and now the times reported are the same.
Code: Select all
620 Instrumental.mp3 | 4262603 | directoryEntryDate > 2013-08-11 17:37:44 | getFileDate > 2013-08-11 17:37:44
630 Instrumental.mp3 | 4262603 | directoryEntryDate > 2013-08-11 17:37:44 | getFileDate > 2013-08-11 17:37:44Code: Select all
I:\library3 > echo %time% %date%
17:11:01.53 Fri 07-31-2026
I:\library3 > dir *.mp3
Sun 08-11-2013 05:37 pm 4,262,603 Instrumental.mp3
I:\library3 > echo %time% %date%
17:11:23.51 Sat 01-31-2026
I:\library3 > dir *.mp3
Sun 08-11-2013 04:37 pm 4,262,603 Instrumental.mp3
I:\library3 >Addendum: I am working with two things.
First, I'm trying out getFileAttributesEx_ to get \ftLastWriteTime which is a quad UTC value. And then and using various posts in the past convert that to a PureBasic time using (PeekQ(@fileData\ftLastWriteTime) - #WIN32_FILE_TIME_OFFSET) / 10000000 I can use that for the definitive "has the timestamp changed"
Next, when I need to display it, I have to convert to local time using FileTimeToLocalFileTime_ ( ). I think I've got a function for that working.
Still, it's curious about PB 6.20 and 6.30, but I think I have a solution.