Milliseconds

[spacebar22]

Is there any way xplorer2 can display time modified including milliseconds?

I have pairs of files created just after 9 AM (hours:minutes.seconds):

e0000005.au 09:00.22
e0000904.au 09:00.22
e0000317.au 09:00.28
e0000cf0.au 09:00.28
e000095c.au 09:00.34
e00007ad.au 09:00.34


But, each pair of files that seem to have the same time are really modified a few milliseconds apart. I need to see that difference so that the time sort is accurate.

Windows knows the file modified time to the nearest millisecond because the information can be got from PowerShell (but I don't know how to do what I want for a directory listing in PowerShell).


Thanks

[Kilmatead]

You cannot display milliseconds in x2 - while NTFS does indeed store times which include that designation, the numbers are by no means representative of accuracy:

...create time has a resolution of 10 milliseconds, write time has a resolution of 2 seconds, and access time has a resolution of 1 day (really, the access date). Therefore, the GetFileTime function may not return the same file time information set using the SetFileTime function. NTFS delays updates to the last access time for a file by up to one hour after the last access.

It's generally accepted that Windows filesystem object Modification timestamps are reliable only to within 2 seconds, regardless of what is actually displayed. So even when PowerShell (or any other utility) show such numbers, there is nothing verifiably true about them in a practical sense, except regarding the Creation timestamp.

To read these times yourself, you would need to access the API directly by writing a script which calls the GetFileTime function from Windows and interpret the resulting FILETIME structure yourself (which is not as simple as it sounds, though by no means impossible - I don't know if PowerShell has that granular capability or not - but other scripting languages certainly do ). But again, the information gleaned would be primarily for educational benefit (regarding Modification [last write time] stamps), and can't be considered a reliable touchstone of accuracy, regardless of what it "looks like".

[FrizzleFry]

it's pretty simple to do in PowerShell

gci | %{$_.name + " {0:yyyy-MM-dd_HH:mm:ss.fff}" -f $_.creationtime}

gci | %{$_.name + " {0:yyyy-MM-dd_HH:mm:ss.fff}" -f $_.lastwritetime}

[Kilmatead]

You know what the unbelievably crazy thing is? Filetimes in Windows are actually stored as the number of 100-nano-second intervals since January 1st in the year 1601. Yes, like 400 years ago. For the uninitiated, 100-nano-seconds is basically 1/10,000th of a millisecond - so the accumulated number of them in the last 4 centuries amounts to a freakishly large number.

In case anyone besides me finds this incredibly curious, numerous threads may be found wherein people posit their own views, but the best one I could locate was this:

It's a pragmatic choice.

The modern western calendar was not consistent until 1752 when Britain (and its colonies) adopted the Gregorian calendar, which had been adopted in most of catholic Europe since 1582.

This is the modern calendar with leap years etc. to keep the 1st of January aligned with the winter solstice.

So why not start from 1st January 1752? Because the basic leap year rule ("It's a leap year if the two digit year is divisible by four except if the four digit century is also divisible by four") established a 400 year cycle. The first full cycle starting on 1st January 1601, (at least in Rome).

The leap year and date calculations are painful enough without starting midway through a four hundred year cycle so 1600 is a pretty good start as long as you remember that any dates before 1752 need to be qualified by a geographic location, as British dates were 10 days out of sync with Roman dates by this time.

And thusly does the Byzantine meet the Renaissance meet the modern-age. Back when I was 12 and was learning C, I found it humorous that C calculated time by the number of seconds since January 1970 - and (as the above article notes) the year 1601 is also how COBOL calculates its dates, though it only counts them in "days since", not nano-bloody-seconds.

It's even more fun when doing this through the API itself, because the time structures have to be interpreted into machine "systemtime" which is UTC (Coordinated Universal Time), which then need to be converted to local-time (daylight-savings, etc), and then finally converted into a string so silly humans like us can make sense of it. Naturally, if trying to "set" a new timestamp yourself, you have to repeat those encoding steps in reverse.

Anyway, just thought I'd offer that bit of trivia to brighten up an otherwise dull day.

And yes, I too did a double-take when I first read about it a few weeks ago for a project I'm punishing myself with - there's something insanely magical about seeing those words in MSDN... "Contains a 64-bit value representing the number of 100-nanosecond intervals since January 1, 1601 (UTC)".

You gotta love it.

[drac]

Kilmatead, I found that very interesting. Thanks for sharing it.

[otlaolap]

"It's a leap year if the two digit year is divisible by four except if the four digit century is also divisible by four"

I'm not quite sure what this means, but it seems to imply that 2000 is not a leap year, but it was. The leap year rule for years ending in "00" (all of which are divisible by four) is that if the year is a multiple of 400 (such as 1600 and 2000) then the year is a leap year; otherwise (e.g. 1700, 1800, and 1900) the year is not a leap year. This is what I remember, and I think I've reported Wikipedia http://en.wikipedia.org/wiki/Leap_year correctly.

[Kilmatead]

As the Wikipedia entry shows, the algorithm is sequentially deductive:

if year is divisible by 400 then
>> is_leap_year
else if year is divisible by 100 then
>> not_leap_year
else if year is divisible by 4 then
>> is_leap_year
else
>> not_leap_year

...so it's not a matter of all the rules being true or even a single rule being arbitrarily true, but for the right one to fall true depending on the order which they are applied and negated - from the looks of things, on a "first-fail/first-succeed" basis. As the primary rule is divisibility by 400, 2000 qualifies, and thus no further rules are applied.

Though, to be honest, it seems a little weird to break down the lunar cycle into such an unromantic pattern - but maybe it's just me.

And I find it mind-boggling that calling it a "bissextile year" never really caught on when that's got such a funky ring to it. "Leap Year" is just too demotic for its own good.

[FrizzleFry]

I find it mind-boggling that calling it a "bissextile year" never really caught on when that's got such a funky ring to it.

That might be fun to read but it seems kinda hard to say...

[Kilmatead]

That might be fun to read but it seems kinda hard to say...

True, but think about it: how many opportunities in this world are there for us to be both pedantic and fun at the same time? Not many, I'll wager. In fact, give or take that there have been (as an average) 24 bissextile years per century, that would be almost 100 missed opportunities since the death of Tycho Brahe and the birth of Louis XIII of France.

(Hey, this is like the one and only time [in the whole universe] that I get to discuss the 17th-century and still be on-topic as regards file-management, so I'm milking it for all it's worth! )

And for all the etymologists out there, we note:

It is called bissextile, because in the Roman calendar it was fixed on the sixth day before the calends of March, (which answers to the 24th day of February,) and this day was counted twice; the first was called bissextus prior, and the other bissextus posterior.

[spacebar22]

it's pretty simple to do in PowerShell

gci | %{$_.name + " {0:yyyy-MM-dd_HH:mm:ss.fff}" -f $_.creationtime}

gci | %{$_.name + " {0:yyyy-MM-dd_HH:mm:ss.fff}" -f $_.lastwritetime}

Thanks for that, and thanks to Kilmatead.

I will use creation time, though modified time is always only 5 or 6 milliseconds later, which seems correct

In Powershell I found how to write to a file:

Code: Select all

start-transcript scriptreport.txt
gci | %{$_.name + " {0:yyyy-MM-dd_HH:mm:ss.fff}" -f $_.creationtime}
stop-transcript

but can you put me right on sorting this result by the creation time? The result now seems to be sorted by file name.

Thanks

[FrizzleFry]

this will sort first by creationtime and then by name (if files have the same creation time)

gci | sort -property creationtime,name | %{$_.name + " {0:yyyy-MM-dd_HH:mm:ss.fff}" -f $_.creationtime}

the % is just an alias for the foreach-object command (cmdlet) so you can use

gci | sort -property creationtime,name | foreach-object {$_.name + " {0:yyyy-MM-dd_HH:mm:ss.fff}" -f $_.creationtime}

it that seems more readable...

sort has a -Descending switch if you want to list the newer files first

gci | sort -Descending -property creationtime,name | foreach-object {$_.name + " {0:yyyy-MM-dd_HH:mm:ss.fff}" -f $_.creationtime}

[spacebar22]

Many thanks, FrizzleFry.

Either of those PowerShell commands give the same output, which is what I need:

e0000317.au 2013-06-06_21:11:23.910
e0000cf0.au 2013-06-06_21:11:23.916
e000095c.au 2013-06-06_21:11:30.005
e00007ad.au 2013-06-06_21:11:30.012
e000059a.au 2013-06-06_21:11:36.097
e0000e55.au 2013-06-06_21:11:36.104
e0000d2a.au 2013-06-06_21:11:42.195
e0000bf2.au 2013-06-06_21:11:42.211
e0000d02.au 2013-06-06_21:11:45.240
e0000bcb.au 2013-06-06_21:11:45.245

So can Xplorer2 do anything with that e.g. if I produce a file from it in Power Shell?

The objective being to physically rename the files while time sorted to give:

e0001.au 2013-06-06_21:11:23.910
e0002.au 2013-06-06_21:11:23.916
e0003.au 2013-06-06_21:11:30.005
e0004.au 2013-06-06_21:11:30.012

and so on.

I know how to use xplorer2 to do this ( e$0001.au in Mass Rename Wizard) except that until accurately time sorted by milliseconds, no-one knows which of each pair of files was really created first.

I cannot attach text files for some reason but the file output is

**********************
Windows PowerShell transcript start
Start time: 20130606212425
Username : hp\gale
Machine : HP (Microsoft Windows NT 6.1.7601 Service Pack 1)
**********************
Transcript started, output file is scriptreport.txt
PS C:\Users\gale\AppData\Local\Temp\audacity_temp\project20649\e00\d00> gci | sort -property creationtime,name | foreach-object {$_.name + " {0:yyyy-MM-dd_HH:mm:ss.fff}" -f $_.creationtime}
e0000317.au 2013-06-06_21:11:23.910
e0000cf0.au 2013-06-06_21:11:23.916
e000095c.au 2013-06-06_21:11:30.005
e00007ad.au 2013-06-06_21:11:30.012
e000059a.au 2013-06-06_21:11:36.097
e0000e55.au 2013-06-06_21:11:36.104
e0000d2a.au 2013-06-06_21:11:42.195
e0000bf2.au 2013-06-06_21:11:42.211
e0000d02.au 2013-06-06_21:11:45.240
e0000bcb.au 2013-06-06_21:11:45.245
scriptreport.txt 2013-06-06_21:20:14.107
PS C:\Users\gale\AppData\Local\Temp\audacity_temp\project20649\e00\d00> stop-transcript
**********************
Windows PowerShell transcript end
End time: 20130606212434
**********************

Thanks again

[FrizzleFry]

you could just do the renaming with a PowerShell script...

Code: Select all

$i=0
gci *.au | sort -property creationtime,name | foreach-object {
	$_.name + " {0:yyyy-MM-dd_HH:mm:ss.fff}" -f $_.creationtime
	$i++
	$newname = 'e' + "{0:D4}" -f $i + $_.extension
	$newname
	rename-item $_ -newname $newname
}

you should probably comment the rename-item command until you are sure you are happy with the names or use a test file set

[spacebar22]

Thanks again, that works perfectly. If I change "D4" to "D5" then I can get a five character renamed file.

By the way XYplorer does have a millisecond time sort like I hoped Xplorer2 might have:
http://www.xyplorer.com/xyfc/viewtopic. ... 59d#p70707 .

The millisecond times are not exactly the same as PowerShell sees for whatever reason, but the creation and modified times do allow the files to be correctly sorted.

Can I lodge a feature request for millisecond support?

[nikos]

have you tried the windows explorer date column? The one without [S], perhaps it has better resolution