I have been using Glasswire for some time now and have a strange error. All events are entered with the wrong timestamp. Everything is 1 hour behind. This means that the 5 min Graph is always empty. All events are visible on the graph, but new date seems to be 1 hour old.
I have tried to find any mention of time-settings in the app, but nothing exists.
I have uninstalled, rebooted and done a clean reinstall. I also checked time-settings on my computer, and everything seems fine on that end.
Have anyone seen this before?
I guess you probably checked and found your Date and Time control panel is correct? I think we just pull the OS date and time, so I don’t know how it could be delayed.
No I do not recall ever seeing this issue. Very interesting! If you go to our top left menu and choose “About” what version of GlassWire do you have? This is GlassWire for Windows or Android?
Its version 2.1.167 running in Windows 10 (with all the latest patches).
Date and time is correct in Windows.
If you create a notepad file or Word doc, then right click it and choose “properties” is the created date correct or is it also delayed?
That shows the correct time
Time differences of one hour are quite common problems. Here’s some ideas:
A difference due to timezones
A timezone difference is between the UTC time used by Windows 10 internally and local time used by Windows Explorer for example.
You can display the time in both Powershell) and the Windows command line. Are they both the same, give or take the time between executing both commands? In this example, they are the same but just displayed with a different format:
Here’s how Powershell can display either UTC and local time.
PS C:\WINDOWS\system32> get-date
Wednesday, 4 December 2019 3:31:56 PM
PS C:\WINDOWS\system32> Get-Date -UFormat "%A %B/%d/%Y %T %Z"
>> $Time = Get-Date
Wednesday December/04/2019 14:49:41 +13
Wednesday, 4 December 2019 1:49:41 AM
Here’s how the Windows command line displays it
The current time is: 13:49:48.50
Enter the new time:
A difference due to the timestamp source used
File timestamps depend upon the file system on the storage partition so that can cause differences:
- NTFS uses UTC
- FAT uses local time
A difference due to daylight saving
This is much less common now. At least since Windows 7.
Timeserver sync issue
In Windows settings, change the time server that you arr syncing to. Or add one if you haven’t already.
Hi, and thank you for alot of interesting information. I did not know NTFS and FAT used defferent time settings. I tryed to change my local time to UTC and that solved the issue with wrong timestamp on logs. But that also mean that the system time is now wrong… I can probably solve that. At least now i know whar causes the issue.
Wow, this is very interesting. Thanks @Remah. I had no idea you could have timing issues like this with Windows depending on the file system.
Windows (and DOS) were timezone-less so FAT never had them either. Then FAT32, exFAT, etc continued this for compatibility.
NTFS, developed much later than FAT, and e.g. Windows NT do have timezones.
I have difficulty getting my head around all the possible interactions but DST is the main one. Most, if not all, file-synchonization software has a feature to cope with it. I use freefilesync and it still has it:
set FFS maximum timestamp difference
to a value higher than your maximum time-zone changes. See the FFS help.
Equally named files at either end of equal size and a timestamp difference
smaller than the maximum timestamp difference will then be considered as “equal”