Hello there,

Not sure if anyone else saw this problem but this comes up a lot with my computers and backup drives like USB thumb drives and just about any other kind of drive.

The problem is that Windows stores files on one drive with a time stamp that is either one or two hours behind the other drive. This is not only annoying, it means that a quick sanity check of the files can no longer be done by just checking the file size and date and time stamp. I'll give an example.

The entries will be in this order:
FILENAME, SIZE, DATE, TIME (where SIZE is the number of bytes of the file)

Drive1:
MyFile1.jpg, 10340 bytes, 2022/03/12 10:41:03

Drive2:
MyFile1.jpg, 10340 bytes, 2022/03/12 08:41:03

Now normally these two files would be considered to be different because they were modified at two different times. However, the time for the second file is exactly 2 hours different (sometimes it will be just 1 hour different) and that is strange right off. The problem is, these two files are exactly the same, byte for byte.

Now other files that are off by 2 hours (or 1 hour) may be really different, so it is possible that those two are different.

See the problem? You cant tell if they are different or not, to be sure.
In most cases the different files will have times that differ by something other than just 1 or 2 hours, but there is a chance that they could really be different.
I think there is a 1 in 3600 chance of them being different if they have times that are off by exactly 1 or 2 hours (no difference in minutes or seconds). That's not really very good odds when you have thousands, hundreds of thousands, or millions of files to check.

Of course i could do a byte by byte file comparison on each and every file, but that of course takes more time. The size and date and time check is fast.
Also of course if the sizes are different than the files are truly different so the problem is only with the date and time.

Also note that it is not as simple as adding or subtracting 1 or 2 hours from one of the file times, because it could mean that it affects the date too. For example,
if date time A is 2022/03/24 23:33:54 and date time B is 2022/03/25 01:33:54 then both the time and date have to be considered, and that means we have to know the number of days in that month because it could also overrun the month itself if it is near the beginning or end of the month, and then also the year if near the end or beginning of the year. That would be more rare, but still a possibility.

Any thoughts on this?

 

I would check your time in BIOS and your system time in Windows, do what you can to make them the same. To me it seems likely your BIOS (RTC) time is 2hrs different from windows system time (due to DST settings and/or time zone) and for some reason Windows is using RTC time for writing the file and system time for backup purposes (or vise versa).

 

I would check your time in BIOS and your system time in Windows, do what you can to make them the same. To me it seems likely your BIOS (RTC) time is 2hrs different from windows system time (due to DST settings and/or time zone) and for some reason Windows is using RTC time for writing the file and system time for backup purposes (or vise versa).

I just copy and paste files from one drive to the other, so not sure what you mean.

 

I just copy and paste files from one drive to the other, so not sure what you mean.

There are two different times in your computer; RTC time and system time. System time (what's displayed in the Windows taskbar) is adjusted for region, daylight savings, etc. while RTC time may or may not be. Usually they are the same, sometimes they are not. I suspect your computer might be (for reasons I can't fathom) using system time for one operation (ex: file>save) and RTC time for others (ex: copy>paste to other drive).

On Linux machines you can view both times with timedatectl and it might look like this:

root@debian-vm:~# timedatectl
      Local time: Mon 2022-09-26 17:17:02 UTC
  Universal time: Mon 2022-09-26 17:17:02 UTC
        RTC time: Mon 2022-09-26 15:17:02
       Time zone: Etc/UTC (UTC, +0000)
 Network time on: yes
NTP synchronized: no
 RTC in local TZ: no

Linux refers to the RTC as the "hardware clock" and has options for synchronizing the two clocks (hwclock --systohc and hwclock --hctosys).

Windows doesn't. Windows tries to hide the fact that there are two clocks. I know of no way to even view the RTC time in windows. The only way I know of to view it on a windows machine is reboot into the BIOS menu and check time there. If you do that, and find it off by two hours, I would consider that a smoking gun. I would put $5 on it being off by 2hrs. Like I said, I have no idea why windows would use RTC time for some things and system time for others (and I've never experienced what you described) but I can't think of any other time source that could introduce an error like this.

 

There are two different times in your computer; RTC time and system time. System time (what's displayed in the Windows taskbar) is adjusted for region, daylight savings, etc. while RTC time may or may not be. Usually they are the same, sometimes they are not. I suspect your computer might be (for reasons I can't fathom) using system time for one operation (ex: file>save) and RTC time for others (ex: copy>paste to other drive).

On Linux machines you can view both times with timedatectl and it might look like this:

root@debian-vm:~# timedatectl
      Local time: Mon 2022-09-26 17:17:02 UTC
  Universal time: Mon 2022-09-26 17:17:02 UTC
        RTC time: Mon 2022-09-26 15:17:02
       Time zone: Etc/UTC (UTC, +0000)
Network time on: yes
NTP synchronized: no
RTC in local TZ: no

Linux refers to the RTC as the "hardware clock" and has options for synchronizing the two clocks (hwclock --systohc and hwclock --hctosys).

Windows doesn't. Windows tries to hide the fact that there are two clocks. I know of no way to even view the RTC time in windows. The only way I know of to view it on a windows machine is reboot into the BIOS menu and check time there. If you do that, and find it off by two hours, I would consider that a smoking gun. I would put $5 on it being off by 2hrs. Like I said, I have no idea why windows would use RTC time for some things and system time for others (and I've never experienced what you described) but I can't think of any other time source that could introduce an error like this.

Ok I'll check that and get back here, but i dont see how copy paste to one drive can be different from copy paste to another drive.

 

Ok I'll check that and get back here, but i dont see how copy paste to one drive can be different from copy paste to another drive.

neither do I

 

neither do I

Actually now that i think about it is this happens after reinstalling Windows.
I backup to a drive with copy and paste, then do that many times, everything is ok.
Then some months later reinstall windows, then suddenly all the times on the backup thumb drive are 1 hour or 2 hours different than on the hard drive the files were copied from before the reinstall.
This is all with the time set to the current time in the area with no DST set (turned off all the time).

It's like windows is shifting the time on one of the drives, and that doesnt make sense either because you would think it was stored on the drive as an absolute time that cant be changed. If files on drive 1 had time 02:00:00 and on drive 2 had 02:00:00, then after reinstall drive 1 has 03:00:00 that doesnt make any sense because how would EVERY time on one of the drives change at all? Doesnt make sense like a lot of other things with the Windows op system. Sometimes i think kindergarten kids are programming this system, really. I would quote a list of things they did over the years that were so stupid you'd really think kids were doing the programming, including but not limited to very very inconsistent ideals version to version, and i do mean VERY inconsistent. It's like when i new guy gets in there they want to do things totally different.

 

Do your drives use the same file system? Windows has some quirks:



from: https://learn.microsoft.com/en-us/windows/win32/sysinfo/file-times

 

When you’ve reinstalled Windows, is the default time zone the same in both installations?
When copying from one drive to another, are the source and destination drive types the same? Different drivers may be executed with a difference in calculating times.

 

Do your drives use the same file system? Windows has some quirks:

View attachment 277171

from: https://learn.microsoft.com/en-us/windows/win32/sysinfo/file-times

That's an interesting idea i'll have to look into that. I did check the bios time and it's the same as the Windows time so i dont think that's a problem.

 

When you’ve reinstalled Windows, is the default time zone the same in both installations?
When copying from one drive to another, are the source and destination drive types the same? Different drivers may be executed with a difference in calculating times.

Yes to the first question, definitely not for the second because one is a hard drive or SSD and the other is a thumb drive. I dont see that as being something that 'should' matter, although it may i guess.

One of the things i never checked was which computer went ahead or back. But this most recent problem the time of the 2nd computer went back 2 hours. So a file that reads 8:00:00 on the host computer reads 6:00:00 on the slave computer. I think that's the first time i've seen a 2 hour difference usually it was just 1 hour.

I always have the time zones set the same obviously because i am always in the same area of the country, except when i travel cross country but then i dont take any of the computers with me. I just take the cell phone but i never tested the difference with that yet. I suspect that the cell phone times are the same as usual so that would put the slave computer still at 2 hours behind the phone too.

BTW the slave computer had the hard drive coming directly from the host computer, with just data stored no op sys. The files that have the data are the ones that read 2 hours behind.

 

Hello again,

I think i may have found a workaround although it is not anything near convenient.

I found that if i go into the clock settings i can set the time zone 1 hour back from what i usually use. I usually have it set for UTC-5 but if i set it to UTC-4 then ALL the times on the files that are 1 hour ahead appear as the right time as set on the computer in the time setting as usual.

This should help when doing the files on another external drive i'll have to see havent tried it yet. It's a pain though.

Then i was also thinking, if i do that, and all the right files change time to the 'correct' time, then i can test the files using the fast method, but then what if one of the files had the time changed because the file actually changed. If that's the case, then again the file would test perfect but have different bytes (although the size would have to match also that's included in the fast test).
So maybe i should go back to my original thought, which was to get the file times (that is the file times that show up in Windows Explorer and in the Windows API when you look at the 'last modified' time) and then just subtract the date and time. As i was saying before, the date could be different if the time overflowed into the next or previous day, so the date and time has to be compared by subtracting and testing to see if the date and time are off by exactly 1 hour, and i should be able to know in advance if i am looking for one hour ahead or behind, so the chances of declaring a bad file good would be lower i think, probably 1 in 7200 chance, but then the size has to be the same also. Unfortunately, when files go corrupt the size does not always change so this is still a little bit of a gamble. If a file is critical enough though i would do a byte by byte comparison.

BTW subtracting one date/time from another date/time is not that simple. It involves using the Gregorian calendar as strange as that seems. That's because when the hour rolls over the day can roll over, and when the day rolls over the month can roll over, and when the month rolls over the year can roll over, and to make it more complicated since not all months have the same number of days and even the years dont always have the same number of days, the actual calendar has to be programmed in. Luckily, i already have that routine so i guess i have to use it.

How stupid is this issue though.