Timestamps Time Differences

[Enternal]

Can someone explain to me why $Time = Property("Write", $Item); always have a difference in the seconds? The hour difference is expected since the time and date reported are in UTC so it should be off by a certain number of hours depending on your location. What bothers me is the second differences which can be off by 0, 1, or 2. The odd thing is that the property window of XYplorer and Windows Explorer shows it "correctly" yet the report UTC is off. That makes me wonder even more which one of these time are the correct one. The one reported from Property() or the one reported by the property window of Windows Explorer and XYplorer?

The reason is I'm trying to synchronized my created file date and time to my modified time. I download files from the internet so they retain their modification date but not their created date so that's why I'm synchronizing them. I have always used Moo0 Timestamps and it works perfectly but just trying to see if I can make a little script to do what I need for certain files that I frequently download. So far it's working almost perfect except for the time difference. If it was consistent, I could have just add or subtract the seconds but it's not consistent either.

[RalphM]

As far as I recall, the seconds reported have never been accurate. (filesys bug me thinks)
But once you got a close enough date/time in a variable you could just timestamp C and M to have them at least identical...

[Enternal]

As far as I recall, the seconds reported have never been accurate. (filesys bug me thinks)
But once you got a close enough date/time in a variable you could just timestamp C and M to have them at least identical...

It's still such an odd problem. Stil, I want it to be exact so it MUST be exact. Therefore instead of using:

Code: Select all

$Time = Property("Write", $Item);
Timestamp ca, "$nDate $nTime", $Item;
$nDate = GetToken($Time, 1, " ");
$nTime = GetToken($Time, 2, " ");

I am using:

Code: Select all

$Time = Report("{modified}", $Item);
Timestamp ca, "$nDate $nTime", $Item;
$nDate = GetToken($Time, 1, " ");
$nTime = GetToken($Time, 2, " ");

Which gives me what I want.

But now it makes me even more confuse. Which one of these is the "truest" or the most exact of the dates. The one we see reported by Windows Explorer (and therefore XYplorer) or the one reported by the api(?) Lol. It got confusing.

[admin]

Looks like a case of "bankers' rounding" to me. At least here it's always the even numbers that are 2 off, and the odd ones are 1 off. The mistake (well, bug) is surely with the shell function (SC Property() uses the shell), not with the API.

[Enternal]

Looks like a case of "bankers' rounding" to me. At least here it's always the even numbers that are 2 off, and the odd ones are 1 off. The mistake (well, bug) is surely with the shell function (SC Property() uses the shell), not with the API.

Wait. I am a bit confused. So SC Property() uses the shell to display the date. But Windows Explorer should be using the shell to display the date as well but there's a difference between the SC Property() and what Windows Explorer is showing. Unless that means Windows Explorer IS NOT using the shell method and is displaying the correct values since it uses a different method of getting the date and time (yet isn't Windows Explorer the shell?) while the Property() is using the actual shell's method of getting the date and time which are rounded and ended up being wrong. Therefore, I should instead use the the Report() method instead to get the values since that's exactly what's being reported by Windows Explorer and should be the correct one. So how does XYplorer gets the value to display in the Status/Find/Properties window?

Wow that's completely messed up.

[admin]

Hm, weird, I agree. My Explorer (XP) does not show seconds at all so I cannot verify this.

[Enternal]

Hm, weird, I agree. My Explorer (XP) does not show seconds at all so I cannot verify this.

Ah I see. It does show under Windows 7. I forgot that XP does not really show the seconds so I guess that's another improvement on 7 hehe. Besides, I think XYplorer is displaying what Explorer should be displaying anyways since they always match up EXCEPT for the SC Property().

[admin]

I rechecked the code and can verify that it's not XY's fault. It's the shell that reports the 2 seconds off.

Tip: Try "#3" instead of "write", it seems to be more reliable (tested here on XP only)

Code: Select all

echo property("#3");

[Enternal]

I rechecked the code and can verify that it's not XY's fault. It's the shell that reports the 2 seconds off.

Tip: Try "#3" instead of "write", it seems to be more reliable (tested here on XP only)

Code: Select all

echo property("#3");

Not at home right now so can't try it yet but will once I get home. But I remember something about this command does not give seconds. I did read here on the forums that each Windows have the property # slightly different so need to play with the other numbers for Windows 7.

EDIT: Ok was able to test it. #3 does not display seconds. Also #4 is for created date and time, #5 is for accessed date and time. #3 is correct from what I saw of the hours and minutes. #4 and #5 however is off by 1 hour. Odd. On Windows 7 32Bit Home.
EDIT2: On Windows XP, it works perfectly fine. Still no seconds but the hours are correct.

Anyway, what is the difference how XYplorer gets the date and time value that is displayed in XYplorer's property window and the SC Property()?

It's really stupid how Windows does this though. So their own Windows Explorer shows the correct value yet when an application ask for it, they incorrectly give or take 2 seconds to it?

[Enternal]

Here is a video of an interesting problem I noticed. Either XYplorer is caching the date value or the shell is. I split it into 2 parts due to file size. Part 1 is the walkthrough and Part 2 is after a quick restart of XYplorer.

Part 1

Time1.gif (970.38 KiB) Viewed 3082 times

Part 2 - After Quick XYplorer Restart

Time2.gif (756.89 KiB) Viewed 3082 times

As you can see in the first one, even after the date and time is changed, XYplorer's Property("Write") [which relied on the shell] and Property("#3") did not correctly show the updated time even though XYplorer's property window AND Windows Explorer property dialog shows the updated time. After a quick restart of XYplorer, both XYplorer Property("Write") and Property("#3") now shows the correct updated time.

[Trasd]

From my understanding, NTFS stores its timestamps in UTC, in a value based representation, and any software that reads this data can be prone to rounding or interpretation differences in the conversion (to local time and such), including the shell, depending on how they do it. Different methods can produce slightly different results. This post got me interested because I remember when writing a program back in FAT days, I was surprised to find there was not enough room to store seconds except in even values. Read about the cached file attribute update delay too, which instead may account for the discrepancy, as alluded to above (second link below).

Here is some information I found:

"NTFS file timestamps, according to the documentation of the ‘FILETIME’ data structure in the Windows Software Development Toolkit, is a  “64-bit value representing the number of 100-nanosecond intervals since January 1, 1601 (UTC)”.

Conversion from this internal format to a format more suitable for human interpretation is performed  by the Windows system call FileTimeToSystemTime(), which extracts the year, month, day, hour, minutes, seconds and milliseconds from the timestamp data. On other platforms (e.g. Unix), or in software that is intentionally platform-independent (e.g. Perl or Java[, Visual Basic?]) other methods for translation is be  required."

I found this here.

There is more info here (about halfway down).

Some of the most interesting data I found is here.

Whether or not this explains the problem (it's a little too technical for me right now as I'm tired), I still find these file attribute storage and retrieval mechanisms interesting.

[admin]

The shell is a "smart" layer between NTFS and the user. The Property() command asks the shell about certain file properties and dumbly reports what the shell spits out. It is only used in scripting because it is practical for the so-called "extended properties" which are not directly accessible by the API. Things like Modified Date however are core properties an XY internally always uses the API to retrieve these. You can use

Code: Select all

text report("{modified}", 1)

to come closer to the truth.

Now, since the shell (due to its smartness) also also relatively slow, XYplorer does a little caching here. And that's where the bug you saw, Enternal, is caused. Fix comes...

Yes, this stuff is interesting. I don't stop being fascinated by the fact that we map a linear progressive time line on a round rotating ball, rotating around another ball. Appears flat (excuse the pun) wrong.

[Enternal]

Yeah! That little caching bug is now gone! Works perfect in that area.

Haha, yes I have already been using Report() as an alternative since it does exactly what I want. It's just that Property() left me a nagging question about why does Window did what it did. So now I understand how it works more. So basically the shell is somewhat of an independent system from what Windows Explorer does and as a result, there is a bit of a difference in how information are obtained.

Yes, this stuff is interesting. I don't stop being fascinated by the fact that we map a linear progressive time line on a round rotating ball, rotating around another ball. Appears flat (excuse the pun) wrong.

Well the whole idea of time had always been an interesting thing anyways considering how complex it could be and how it breaks down at a macro scale and at a microscale. However at the scale we're using, it all works. Crazy stuff.