Touch command is off by 1 hour

[Dick Johnson]

I wanted to set the time and date of a file to something that would make it obvious if the file was modified. So I used the command:

touch /d1-1-2018 /t1:01 filename

But this resulted in a file with a timestamp of 12:01, not 1:01. In order to get a file with a timestamp of 1:01 I had to use 2:01 in the Touch command.

Why is Touch off by an hour?

Using TCC standalone v 22.00.40, but I have noticed this in earlier versions as well.

 

[gentzel]

Does using the u suffix to specify UTC work as expected?

 

[vefatica]

I think we're stuck with this behavior for the sake of compatibility with CMD. After your command, here's what CMD says, and what Explorer says.

V:\> ver

Microsoft Windows [Version 6.1.7601]

V:\> dir fi* | grep filename
2018-01-01  01:01                 0 filename

 

[Charles Dye]

touch /d1-1-2018 /t1:01 filename

But this resulted in a file with a timestamp of 12:01, not 1:01.

Why is Touch off by an hour?

To clarify — if you don't understand it already — TOUCH is fine; it's DIR that's wrong. January 1st we were on Standard Time time; now we're on Daylight Savings Time. DIR's display of timestamps is off by an hour, one way or the other, when you cross DST changes like that.

It would be trivial for Rex to fix, but then he'd be incompatible with CMD.EXE.

 

[vefatica]

No, in fact, TOUCH is not fine. Here, this command

touch /c /d2018-01-01 /t1:01 filename

gives the file the timestamp

131592564600000000

(verified independently of TCC).
That number is UTC for 2018-01-01 05:01.

v:\> echo %@eval[(131592564600000000 / 10000000) mod 86400]
18060

IMHO, that's wrong. At 2018-01-01 01:01 here, UTC was 2018-01-01 06:01

I'm in U.S. Eastern. TOUCH applied the current (DST) 4-hour difference in creating the timestamp, not the 5-hour (EST) difference that was in effect on 2018-01-01.

TOUCH might benefit from using TzSpecificLocalTimeToSystemTime(). That function is not used at all by TCC. It's "inverse", SystemTimeToTzSpecificLocalTime(), is used by TCC sometimes. It would seem a good idea to ALWAYS use both those functions, symmetrically, but that probably wouldn't get along with CMD, which seems not to use either of those functions.

FWIW, PowerShell agrees with Explorer (and disagrees with CMD).

v:\> echo %@pshell[dir v:\fi*]


    Directory: V:\


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----       2018-01-01     00:01              0 filename

 

[vefatica]

To clarify further, because DIR seems to apply the current TZ offset rather than the one in effect at the time. This agrees with CMD, and disagrees with Explorer and PowerShell.

v:\> ver

TCC  22.00.41   Windows 7 [Version 6.1.7601]

v:\> d filename
2018-01-01  01:01               0  filename

 

[Dick Johnson]

To clarify — if you don't understand it already — TOUCH is fine; it's DIR that's wrong. January 1st we were on Standard Time time; now we're on Daylight Savings Time. DIR's display of timestamps is off by an hour, one way or the other, when you cross DST changes like that.

It would be trivial for Rex to fix, but then he'd be incompatible with CMD.EXE.

I'm not seeing a problem with DIR. When I run the Touch command, DIR reports the correct time stamp:

But I almost never use DIR. Windows Explorer, which is what led me to report this problem, is off by an hour:

It would appear that Windows Explorer isn't displaying the timestamp as I set it. Apparently, it is trying to be "smart" and set the time back one hour since we weren't on DST on Jan.1 ????



Also, the TCC @filetime function returns the proper 1:01 timestamp. So, I guess it is a Windows bug and another example of what goes wrong when you try to make software "smart".

 

[vefatica]

But I almost never use DIR. Windows Explorer, which is what led me to report this problem, is off by an hour:

That's because TOUCH set it wrong in the first place. And DIR and @FILETIME make the complementary mistake. They all add/subtract the CURRENT Standard/Daylight offset when converting local time to/from FILETIMES (which are UTC) ... regardless of what was in effect at the date/time in question.

Because it was DST on April 26, TOUCH used the DaylightSaving difference in converting to UTC even though on 2018-01-01, the StandardTime difference was in effect. The timestamp is simply wrong. You can see that below. The difference between the specified date and the UTC timestamp is 4 hours (I'm in US Eastern), not 5 hours as it was on 2018-01-01.

2018-01-01 01:01:00.000 US EasternStandardTIme is 2018-01-01 06:01:00.000 UTC. And it always will be. TOUCH got it wrong.

v:\> touch /c /d2018-01-01 /t1:01 filename
2018-01-01 01:01:00.000  V:\filename

v:\> echo %@fileage[filename,u]
131592564600000000

v:\> echo %@agedate[131592564600000000]
2018-01-01,05:01:00.000

Even though that timestamp is wrong, Explorer did the right thing ... knew the difference was 5 hours on 2018-01-01 and turned that 2018-01-01,05:01:00.000 (UTC) into 2018-01-01 00:01:00.000 (local).

Notice how the file's write time changes! Was it written at 01:01 or at 00:01 on 2018-01-01? Below, I haven't changed the file's timestamp. But at different times of the year, it gives me different results.

v:\> date /t

Wed 2018-05-09


v:\> dir /k /m filename

2018-01-01  01:01               0  filename


v:\> date 2018-01-01


v:\> date /t

Mon 2018-01-01


v:\> dir /k /m filename

2018-01-01  00:01               0  filename

 

[Dick Johnson]

Even though that timestamp is wrong, Explorer did the right thing ... knew the difference was 5 hours on 2018-01-01 and turned that 2018-01-01,05:01:00.000 (UTC) into 2018-01-01 00:01:00.000 (local).

And yet, when I use TCC to set the file time to 1:01 the DIR command in cmd.exe also shows the timestamp of 1:01, which is exactly what I would expect. Only Explorer shows a different time.

Today I learned: they've really made a mess of date/time handling.

 

[vefatica]

And yet, when I use TCC to set the file time to 1:01 the DIR command in cmd.exe also shows the timestamp of 1:01, which is exactly what I would expect. Only Explorer shows a different time.

Today I learned: they've really made a mess of date/time handling.

Leave that file alone until Standard Time is in effect again. Then DIR will get it wrong.

 

[vefatica]

And yet, when I use TCC to set the file time to 1:01 the DIR command in cmd.exe also shows the timestamp of 1:01, which is exactly what I would expect. Only Explorer shows a different time.

Explorer IS the smart one, applying the timezone offset (TZO) at the time of the file's timestamp. CMD and TCC always apply the current TZO, regardless of the file's date.

As I said before, "touch /d1-1-2018 /t1:01 filename" adds the current (daylight) offset to get UTC. That's not correct for 1-1-2018. So the file's timestamp is wrong. DIR makes the same mistake in the other direction (subtracting the current offset) so it looks right (now).