Hi there.
Just noticed one thing that I would like to share. Windows Explorer shows 1 hour less than SwiftSearch for the same file, but not with all files. Especially files that are written (modified) /created before the end of March do not match with Explorer and SwiftSearch.
I know it has something to do with Daylight Saving feature which GMT time zone changes one hour forward and back interchangebly on October and March. Files that are written after 1st of April has no such problem and SwiftSearch matches with Explorer.
I am adding a screnshot here as attachment.
Hope you clarify and I hope it is not an unexpected behavior as I am quite sure NTFS is not daylight saving aware but I want to know more about this inconsistency.
Very interesting, thank you for reporting this. It may be due to how I convert the binary file time to text... I'm not sure. Could you try right-clicking the file and clicking "Copy Row(s)", then pasting into somewhere (like Notepad) and seeing if the timestamp matches what you see in the main window or whether they are different?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2018-12-18
I would try it later, thanks.
However what irritated me is that my main Windows 7 x64 machine has this problem with the same SwiftSearch version, and the older Vista x32 machine does not have this problem as both have NTFS file systems as well, and locale time zones are set to correct GMT (GMT +3). Both SwiftSearch executables are running *32 (32 bit, x86) process according to task manger.
Still i'm not sure why this mismatch does occur and which one is showing the correct time?
Do you have any insight on this?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't know honestly, I have to spend some time reproducing it in order to investigate it. It could be a bug in my program, a bug in the system, out-of-date timezone information that for some reason affects Windows but not SwiftSearch (I have no idea why this would happen), or something else...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2018-12-18
Hi again.
My time zone is Turkey. I did some additonal testing and I think that the inconsistency relies on the files that had been created just before the installation of Microsoft patch released on 2 years ago, on October 2016, which updates time zone information for Turkey, switching from GMT+2 to GMT+3 without any daylight saving feature decided by government since the end of 2016.
And for the testing, when I check files older than October 2016, in any year between 1st November-1st April (winter) that problem resides. However many files written/created approximately between 1st April-1st November (summer) are fine and not affected by this bug. Hence no 1 hour lag. Also Explorer shows exact file timestamps for these old existing files (which are older than 2016) and these files' timestamps are not adjusted (not 1 hour forwarded) to new time zone (GMT+3) even after this patch, based on Explorer. So the problem is between SwiftSearch and Windows. SwiftSearch shows timestamps from NTFS metadata directly but I don't know why Windows is still showing exact correct timestamps after that patch having 1 hour lag between SwiftSearch though.
Additionally, files that are newer than the date of this patch (newer than October 2016) do NOT have this 1 hour lag problem regardless the summer/winter timestamp season and they are fine, matches with SwiftSearch. Recent files are fine though.
I am quite (in fact very) confused and couldn't find a definite explanation for this, and had no such observation until using SwiftSearch.
I hope things are not faulty and unexpected.
Best regards.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2018-12-18
Here is what I found additonally.
For some reason, on Windows 7, Explorer (file properties) shows 1 hour less for these problematic timestamped files eliminating new time zone difference, BUT running "dir" command from Command Prompt prints exactly same timestamp with SwiftSearch.
Confused more.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Interesting! The fact that the command prompt does the same thing as SwiftSearch tells me that what Microsoft probably did is to change Explorer to account for the time zone change so users can see the right dates and times, but decided not to modify core Windows components in order to avoid breaking other programs.
If that's the case, I'm not sure what I can do about it, since I don't know where Explorer gets its data from that the rest of Windows doesn't. However, it might be interesting to see what date is actually stored in the file system. Could you try a couple of things?
Switch your time zone to something else (like GMT), reboot (in case it's necessary), and see if the time you see in SwiftSearch matches that in Explorer.
Use the FileTest program with to get the raw timestamp of your file, and post a screenshot here. You can do this by entering the file path in the "File name:" box and select OPEN_EXISTING and press "CreateFile", then when the file is successfully opened, go to the NtFileInfo tab and press NtQueryInformationFile (with FILE_BASIC_INFORMATION selected). This might provide useful information; I'm not sure.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's damn annoying and interesting that Microsoft Windows Explorer is causing such a mess understanding the difference between Command-Line (and Switfsearh) and Explorer, which is a real discrepancy. If i find any chance to try the things above like changing GMT zone and FileTest, i'll update here.
Thanks a lot!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi there.
Just noticed one thing that I would like to share. Windows Explorer shows 1 hour less than SwiftSearch for the same file, but not with all files. Especially files that are written (modified) /created before the end of March do not match with Explorer and SwiftSearch.
I know it has something to do with Daylight Saving feature which GMT time zone changes one hour forward and back interchangebly on October and March. Files that are written after 1st of April has no such problem and SwiftSearch matches with Explorer.
I am adding a screnshot here as attachment.
Hope you clarify and I hope it is not an unexpected behavior as I am quite sure NTFS is not daylight saving aware but I want to know more about this inconsistency.
Best regards.
Very interesting, thank you for reporting this. It may be due to how I convert the binary file time to text... I'm not sure. Could you try right-clicking the file and clicking "Copy Row(s)", then pasting into somewhere (like Notepad) and seeing if the timestamp matches what you see in the main window or whether they are different?
I would try it later, thanks.
However what irritated me is that my main Windows 7 x64 machine has this problem with the same SwiftSearch version, and the older Vista x32 machine does not have this problem as both have NTFS file systems as well, and locale time zones are set to correct GMT (GMT +3). Both SwiftSearch executables are running *32 (32 bit, x86) process according to task manger.
Still i'm not sure why this mismatch does occur and which one is showing the correct time?
Do you have any insight on this?
I don't know honestly, I have to spend some time reproducing it in order to investigate it. It could be a bug in my program, a bug in the system, out-of-date timezone information that for some reason affects Windows but not SwiftSearch (I have no idea why this would happen), or something else...
Hi again.
My time zone is Turkey. I did some additonal testing and I think that the inconsistency relies on the files that had been created just before the installation of Microsoft patch released on 2 years ago, on October 2016, which updates time zone information for Turkey, switching from GMT+2 to GMT+3 without any daylight saving feature decided by government since the end of 2016.
Article here:
http://support.microsoft.com/kb/3192321
And for the testing, when I check files older than October 2016, in any year between 1st November-1st April (winter) that problem resides. However many files written/created approximately between 1st April-1st November (summer) are fine and not affected by this bug. Hence no 1 hour lag. Also Explorer shows exact file timestamps for these old existing files (which are older than 2016) and these files' timestamps are not adjusted (not 1 hour forwarded) to new time zone (GMT+3) even after this patch, based on Explorer. So the problem is between SwiftSearch and Windows. SwiftSearch shows timestamps from NTFS metadata directly but I don't know why Windows is still showing exact correct timestamps after that patch having 1 hour lag between SwiftSearch though.
Additionally, files that are newer than the date of this patch (newer than October 2016) do NOT have this 1 hour lag problem regardless the summer/winter timestamp season and they are fine, matches with SwiftSearch. Recent files are fine though.
I am quite (in fact very) confused and couldn't find a definite explanation for this, and had no such observation until using SwiftSearch.
I hope things are not faulty and unexpected.
Best regards.
Here is what I found additonally.
For some reason, on Windows 7, Explorer (file properties) shows 1 hour less for these problematic timestamped files eliminating new time zone difference, BUT running "dir" command from Command Prompt prints exactly same timestamp with SwiftSearch.
Confused more.
Interesting! The fact that the command prompt does the same thing as SwiftSearch tells me that what Microsoft probably did is to change Explorer to account for the time zone change so users can see the right dates and times, but decided not to modify core Windows components in order to avoid breaking other programs.
If that's the case, I'm not sure what I can do about it, since I don't know where Explorer gets its data from that the rest of Windows doesn't. However, it might be interesting to see what date is actually stored in the file system. Could you try a couple of things?
Switch your time zone to something else (like GMT), reboot (in case it's necessary), and see if the time you see in SwiftSearch matches that in Explorer.
Use the FileTest program with to get the raw timestamp of your file, and post a screenshot here. You can do this by entering the file path in the "File name:" box and select OPEN_EXISTING and press "CreateFile", then when the file is successfully opened, go to the NtFileInfo tab and press NtQueryInformationFile (with FILE_BASIC_INFORMATION selected). This might provide useful information; I'm not sure.
Hi wfunction,
I ended up reading and relying on this article which states that Explorer has changed its way to report timestamp insisting on the actual time, ignoring DST offset:
https://blogs.msdn.microsoft.com/oldnewthing/20130308-00/?p=5023
It's damn annoying and interesting that Microsoft Windows Explorer is causing such a mess understanding the difference between Command-Line (and Switfsearh) and Explorer, which is a real discrepancy. If i find any chance to try the things above like changing GMT zone and FileTest, i'll update here.
Thanks a lot!
Awesome, thanks for reporting back! Sounds kind of like what I expected.