Msecs "reloaded"

[nerdweed]

Can these bits be used to store the tags and labels in the File system. Obviously only XY can read it. Question: if msecs isn't timestamped, will the previous msecs be present. I doubt, but since Don said there are 27 bits to utilize, it may be possible

[admin]

Can these bits be used to store the tags and labels in the File system. Obviously only XY can read it. Question: if msecs isn't timestamped, will the previous msecs be present. I doubt, but since Don said there are 27 bits to utilize, it may be possible

Yes, theoretically, but I don't plan to mix tags with this. You can rather use the 27 bits for your private purposes. Every app can read it that can deal with NTFS timestamps. But, read on... ... ...

... "Question: if msecs isn't timestamped..." hmm, good point! No, currently anything that's not explicitly stamped is set to zero. Also, when modified date is changed by writing to the file, Windows will not care about your extra bits but kill them. So, let's forget my stupid 27-bit idea! Crap.

[Marco]

Don, thank you for datediff() and compare() [this is rehab for your caffeine addiction...]

Re 27-bit personal bits and microseconds...

If a file is set as readonly because you don't plan to modify it, then you have three dates that don't change, each one with a theoretically maximum of 7 digits after the seconds. So 21 decimal digits, each one worth roughly 4 bits.
But if the file is modified then only two dates remain fixed, so you drop to 14 decimal digits.
I suppose you can use such info in pair with Color Filters?

If the full time resolution would be supported then datediff() would take "f" as parameter instead of "ms". It would be more consistent with the other functions (now and report). Conversion to microseconds or milliseconds or every other power of ten would be a trivial division by ten.
And you would reach the finish line cause 100-ns is the highest accuracy within NTFS

PPS: timestamping each digit after the seconds may be tedious. You could maybe internally pad the data entered with zeroes. In fact if I try to run this

Code: Select all

timestamp , "<date yyyy-mm-dd> 12:00:01.5";

I get an error because it expects all the three digits after the period. Minor suggestion.

[admin]

Thanks for the salad!

Color Filters already supports "ms".

All agreed. I will add 100-ns precision and autopadding of zeroes to time-stamping. And optional display of microseconds.

I will also correct the order components with UTC "Z". "Z" should always be the last part of the time string.

[admin]

Well, to draw a line under this chapter: When you are after file time precision XY leaves no panty dry.

[Marco]

Well, to draw a line under this chapter: When you are after file time precision XY leaves no panty dry.

Awesome work with 12.40.0304 Don, my congratulations!!

Just a minor glitch: in the IP the form hh:nn:ssZ.fffffff is applied, i.e. the Z is not the last thing as you wanted. The form in the List is the correct one, by the way.

And one minor remark - re datediff: if you don't want to use the official SI prefix "µ" (understandably, since only folks from Greece could type it without major hassle), you could still rely on "u" (which is kind of kosher for the purpose) and thus have "us" as switch, which makes slightly more sense than "mc". And adding the switch "ns" for nanoseconds too would bring ultimate time resolution support/capability to datediff().

Then XY won't leave any panty dry.
[but, I admit, I've never heard such expression before ]

[admin]

Cool, thanks for the glitch, and the "us".