Found something interesting: TC's files have nice timestamps

[MaxX]

I've just found something interestng.
All files from TC's package have the nice timestamps:
version 9.0 - time 9:00
version 9.21 - time 9:21
version 9.50 - time 9:50
version 10.0 - time 10:00
version 10.50 - time 10:50
version 10.51 - time 10:51
version 10.52 - time 10:52
version 11.0 beta - time 11:00

Did anyone notice this too?

[Gral]

Yes, probably most longtime users have known about it for a very long time.

Oldest version which i have ready to run 3.01 - time 3:01

Note also that TC never reached xx.60 version, guess why?

[Sir_SiLvA]

Note also that TC never reached xx.60 version, guess why?

that is only true if u dont count that TC startet as WC

some other versions:

WindowsCommander Version 1.10e	0:10
WindowsCommander Version 1.12e	0:12
WindowsCommander Version 1.13e	1:13
WindowsCommander Version 1.22	17:10
WindowsCommander Version 1.61	1:51
WindowsCommander Version 2.00	2:00
WindowsCommander Version 2.01	1:01
WindowsCommander Version 3.01	2:01
WindowsCommander Version 4.03	3:03
WindowsCommander Version 5.00	4:00

[MaxX]

2Gral
> Note also that TC never reached xx.60 version, guess why? :lol:
That's why it could be better to add 0.1 rather then 0.5 each major release. :lol:

[Gral]

2 Sir_SiLvA
Version 1.61 - this one I missed, probably never used, certainly not at release time. I counted from the first 32-bit version, I remember them rather well. I think that all but one inconsistencies in the times given by you are due to copying between disks with various file systems FAT <-> NTFS

[Sir_SiLvA]

I think that all but one inconsistencies in the times given by you are due to copying between disks with various file systems FAT <-> NTFS

No seems to be a TC(addon?) error ie if enter with page+down install.bin of WindowsCommander Version 3.01 it shows the time of WINCMD32.EXE as 2:01
(same when I rename the ending to zip and do it in explorer) but if I open install.bin in WinRar the time of WINCMD32.EXE is 3:01

[beb]

One day TC reaches the 25th version and the world will switch to the 25-hour civil day on a regular basis (now this is the case only once a year where daylight saving time is practiced), then to 26, and so on.

ps I noticed the timestamping principle with my own eyes upon one "silent" update when the package was updated soon after the release while the timestamps inside remained the same (then I checked other packages and the correspondence between timestamps and version number became apparent).

[MaxX]

2Sir_SiLvA
Daylight saving time +1?

[beb]

Daylight saving time +1?

Regular time +1: now it happens when we set clocks back by one hour in the fall ("fall back") to return to standard time (i.e., when we are switching off the 'daylight saving time' and turning on 'regular/standard time' back again, and this day becomes by one hour longer).

Edit
2MaxX, oh, apparently you've referred to the one-hour difference in Sir_SiLvA's versions-vs-timestamps table. Thus, this comment is mostly irrelevant. Sorry.

[MaxX]

2beb
DST does too much brain pain anywhere.

[Sir_SiLvA]

Sorry I have no idea why the time is displayed in TC and Explorer with one less hour then in (for example) WinRar.
if you wanna look for yourself at v1.10-5.11 I uploaded them as one (23mb) 7z archive here: https://zippysha.re/D3S0K1udzf/Windows_Commander_v1_10_5_11_7z

@mods: if that makes trouble with m*soft please delete the link.

[MaxX]

2Sir_SiLvA
I see the same. That is DST joke of ZIP.
Just wait for winter and open your files then. You'll see proper time.

[MaxX]

If you want to get proper dates from ZIP archive (also - on FAT32, .ISO images, etc.) you should look at summer files in summer and look at winter files at winter.

[petermad]

If you want to get proper dates from ZIP archive...

Or set NewTimeZoneMethod=0 in the [Configuration] section of your wincmd.ini.