[8.0b1 - x64 + x86] Time issues on certain files and dirs.

[Kishiro]

When comparing the 8.0b1 Build (both x64 and 32-bit) to the previous version, 7.56a, I discovered that certain files and directories were off in timestamps of approx. an hour. Not all files, just some. weird... I used the same ini file on all the builds, and I ALT+Tabbed between them.

Image: http://home.lyse.net/kishiro/images/tc/tc_time_bug.png

[Kishiro]

Update; After comparing in various programs and explorer itself, I've concluded that the bug must be in the old 7.56a version not the new 8.01 version.

Moderator; you can delete this thread if you like. or movie it to the "TC7.56(a) bug reports (English)" sub-forum.

[Hacker]

24.07.11 Added: wincmd.ini [Configuration] NewTimeZoneMethod=1/0 sets new Windows 7 time zone method (32/64)
24.07.11 Added: Windows 7: Use new timestamp display method as in Explorer (32/64)

Perhaps?

Roman

[karlchen]

Hi, Roman.

Great.
Yet, I am afraid I still wonder what this new method is in detail.
Have you got any idea? Else we may have to wait for Christian to explain.

Cheers,
Karl

[Sob]

It's how DST is handled. To see what's going on, I used simple script to create 365 files with dates from 2011-01-01 to 2011-12-31 (one file per each day) and time 12:00 (noon) UTC.

My default timezone is UTC+1 and UTC+2 when DST is active.

With current system date (DST active):
- TC 8: from 2011-03-27 to 2011-10-29 the time is 14:00, the rest 13:00
- TC 7: time for all files is 14:00

With december 2011 as system date (no DST):
- TC 8: from 2011-03-27 to 2011-10-29 the time is 14:00, the rest 13:00 (same as before)
- TC 7: time for all files is 13:00

Explanation:
TC 8 shows time related to the date of each file and timezone which was valid at that date = times stay always the same.
TC 7 simply takes UTC and adjusts it according to timezone valid now = times change depending on whenever DST is currently active or not.

My vote goes to TC 8.

[karlchen]

Hello, Sob.

Thanks for taking the time of investing this and explaining it so nicely.
Yep, agreed, the new TC 8 approach where the displayed timestamps remain unmodified in summer and in wintertime seems more logical to me as well.

So the reported behaviour is a feature rather than a bug.

Cheers,
Karl

[petermad]

It works OK for NTFS partitions, but unfortunately it also works on FAT and archives, which it should not.

The time is always the same on FAT partitions and in archives and should not be adjusted according to timezone and DST, but with NewTimeZoneMethod=1 they unfortunately are. This results in different time for for example unpacked files depending on whether DST is active or not, and whether they are unpacked to FAT or NTFS.

[Sob]

It depends how time is stored. NTFS with times in UTC is fine, because it always refers to exact moment. For FAT using local time, there's really no hope at all, because it can mean anything. So the least wrong approach is to show it as is. If TC adjusts it, I'd say it's bug.

The same rules apply for archives. If archive stores UTC, then there's no problem, because it's exact time. If it stores local time, then again better not touch it. If I created modern archiver, I'd definitely use UTC. But what popular formats actually use, I have no idea.

[ghisler(Author)]

Yes, it's a new feature to show the same times as in Explorer (and Alt+Enter properties).

It depends how time is stored. NTFS with times in UTC is fine, because it always refers to exact moment. For FAT using local time, there's really no hope at all, because it can mean anything. So the least wrong approach is to show it as is. If TC adjusts it, I'd say it's bug.

Unfortunately the Explorer does the same, so it's better to do it also in TC...

[petermad]

How about making it optional:

NewTimeZoneMethod=2

= don't change time when UTC-time is not nown (FAT, most archives)

[ghisler(Author)]

That would indeed be nice, but I fear that checking the file system for every single file would be terribly slow. This would be necessary because NTFS also allows hard links to files on other drives, even FAT.

[Flint]

This would be necessary because NTFS also allows hard links to files on other drives, even FAT.

Hard links on files from different partition are impossible, because hard links are just a counter in NTFS internal structure. The file must be located inside the same file system for it to work.

NTFS can store symbolic links to files from different partitions (starting from Vista), but AFAIK the link has its own timestamp, so it does not have to be re-checked separately. And NTFS can store symlinks to directories on different partitions, but when you enter such a directory by a symlink, all the files in it will be on the same partition, so it is not necessary to check every file.

[ghisler(Author)]

You are right, it was about directories, not files. It's still not se easy, e.g. in case of branch view or search - feed in listbox.

[petermad]

2ghisler(Author)

Unfortunately the Explorer does the same

That depends on the OS. Here Explorer under Win XP shows the untouched time of files in archives, but changes the time for the same files under Win 7.

Maybe at least keep the "old way" for archives...

[Flint]

It's still not se easy, e.g. in case of branch view or search - feed in listbox.

Ah, right. I didn't think about them.