ZTree.com  | ZEN  | About...  

 Index   Back

[Bug] CO-1M 'Yes' can cause entered times to be off by an hour (revised)   [Zeta]

By: John Gruener     Orlando, Florida  
Date: Jun 01,2019 at 18:41
In Response to: [Bug] CO-1M 'yes' causes copied timestamps off by 1 hour between opposite DSTs (Liviu)

> For example, while in CT timezone (currently having DST in effect):
> - take a file with timestamp '1-06-2017 2:45:52' (when DST was *not* in effect);
> - then [N]ew-date, TAB, Ctrl-Ins to copy the original timestamp;
> - choose any (other) file, [N]ew-date, Shift-Ins to paste the previously copied tmestamp;
> - the target file gets (wrongly) stamped as '1-06-2017 1:45:52' instead.

(This is a revision of my previous response, which I deleted).

The problem is that when CO-1M=Yes, the entered time is always changed if the file date is in the opposite Standard/DST 'zone' from the current one. (For simplicity here let's call them 'ST' and 'DT' for Standard Time and Daylight Time).

To see this while in DT, simply enter a new time on a file in ST (or change the date to ST). ZTree automatically subtracts an hour. Do this again to that file, changing only the date to another ST date, and ZTree will subtract another hour.

Because I don't want to change the date on my computer I've not tested this, but my guess is if you are in ST and enter a time on a file dated in DT, it will add an hour.

The original request, followed by discussion about how Explorer and Console display the time differently, is here:

The request was simply to display the time like Explorer now does. ZTree should treat a timestamp entered (or pasted) as the time that was in effect for that ST/DT zone, so it will display as entered.

However, this may be easier said than done (and is the reason for this revised post). While it appears that ZTree is intentionally changing the entered time, that may not be the case. In NTFS the time is stored in UTC. I don't of course know how ZTree is internally handling the entered time, or at what point it gets converted to UTC. But if the entered time is internally converted to UTC, and that conversion is done for the current ST/DT zone, this would result in the UTC time applied to an opposite ST/DT date being off by an hour.

When CO-1M=No the same thing happens, but the error is not evident because ZTree is not converting the displayed time for the opposite zone. Those of us who find some file times important have learned to live with all NTFS times changing when the current ST/DT time changes, making all files in the opposite zone off by an hour. Also we must be careful when using a program like JHead to make a .JPG file timestamp the same as the internal EXIF. If this is done on a file in the opposite zone, the file time will be off by an hour for that zone.

I find it a welcome change that Explorer now displays the time correctly. Surprisingly it does this on the FAT FS as well as NTFS, and is what ZTree CO-1M is doing as well.

So whether or not I'm correct about the reason for this error, to avoid it when CO-1M=Yes, any timestamp that is entered (or pasted) will need to have the internal time set for the target ST/DT date before being applied. This would also fix the problem with JHead applying the wrong time to .JPG files in the opposite zone. In short, with CO-1M=Yes everything should work as the user expects.

If anyone sees some potential flaw or problem with doing this, please respond.

- John

Thread locked

Messages in this Thread

95,097 Postings in 11,989 Threads, 350 registered users, 80 users online (0 registered, 80 guests)
Index | Admin contact |   Forum Time: Sep 21, 2020 - 2:37 pm EDT  |  Hits:34,181,853  (15,009 Today )
RSS Feed