How to display a date field like date created or date modified with millisecond precision?

Help & Support
1

I would like to request a feature that lets you see the milliseconds for a date time field like date created or date modified. I want to differentiate between some files that all have the same date created to the second. They were created very quickly with a script, so the second is not unique. This is an example with Free Commander. Is there a way to display milliseconds in Directory Opus? It seems like these links might describe a way to do it.
https://www.gpsoft.com.au/help/opus12/index.html#!Documents/Codes_for_date_and_time.htm

However, I could not figure out how to add milliseconds in Directory Opus. I tried with version 13 first and then with version 12. Neither version worked. For example, notice that all of these files have a date modified value of 2024-04-07 20.27.43. I do not know what the millisecond time is.

Windows-10-x64-on-c-drive-e29a8a59-db49-4fe7-9f31-4a0c71df7d5f-2024-04-09-06-41-38
Windows-10-x64-on-c-drive-e29a8a59-db49-4fe7-9f31-4a0c71df7d5f-2024-04-09-06-41-381914×1027 108 KB

If such a feature does not exist, I would like to request the ability to view milliseconds in Directory Opus. This could be added a future release. This is a feature request. And if possible I would even like to see microseconds and nanoseconds. I think NTFS is precise to 100 nanoseconds.
Microsoft Copilot suggested using wmic to get the date a file was created, but it didn't work. wmic didn't work and Powershell only displayed the date to the second.
wmic datafile where name="c:\path\to\your\file.txt" get creationdate

WindowsTerminal_JCXkytz6cZ
WindowsTerminal_JCXkytz6cZ1920×1200 145 KB

XYplorer can display milliseconds.
76zDIy3a0w
76zDIy3a0w1920×1200 381 KB

SlIovJmSWE
SlIovJmSWE1920×1200 375 KB

2

Try checking Preferences / File Display Columns / Options / Show milliseconds.

2 Likes
3

Does Directory Opus support 0.0001 seconds and more precise specifications such as microseconds and nanoseconds? Xyplorer supports up to 10^-7 seconds.
You type ::msecs 1, 7; in the address bar.

image
image1920×1200 275 KB

4

Opus displays the milliseconds to 3 decimal places, but it should be possible to show the entire value by creating a custom column via classic scripting (the Evaluator columns also reduce milliseconds digits to 3 decimal places).

5

Does it? Can you give an example? Here's the best I could find:

var d = DOpus.Create().Date();
DOpus.Output(d);
DOpus.Output(d.ms);
DOpus.Output(d.Format("T#MHH:mm:ss"));

image
image1210×909 23.6 KB

6

Ah I didn't realize that in the classic scripting Date objects that are received for Item are Opus' objects and not JS/ActiveX dates.

So it seems the higher resolution custom column can only be achieved by querying the files manually via some ActiveX interface rather than via Opus built-in facilities.

7

Is there an actual use for timestamps of this precision?

8

There is in situations like:

9

Are milliseconds really not good enough though?

10

I'd imagine that scripts generating files might be fast enough depending on the storage medium write speed (especially if concurrency is involved). Seems like an edge case situation though (I myself never had such situation).

11

I used to XYplorer to view to 100 nanoseconds precision.

12

In the original screenshot the files are named incrementally anyway, so I'd assume 2002-W10-2 has been created after 2002-W10-1, and having 214k objects with 0 bytes would have accordingly 0 (or near 0) practical meaning. Any script which can create 214k files with non-zero bytes content would definitely require more than 1 nanosecond to create all those files and the whole question would be moot anyway.

2 Likes
13

I like seeing the difference in the date time created.

14

The thing you asked for (milliseconds) is there already.

I don't think we're going to add even finer detail to any built-in column. Even milliseconds are a little ridiculous, IMO, for displaying file timestamps.

Note that sorting will always consider the full timestamp resolution, so the precision of what's displayed doesn't affect how things are ordered if you sort by date.

2 Likes
15

Thankfully XYplorer supports full precision. I was also thinking of making my own custom file explorer with a Java GUI that would display full precision.

16

How would I implement it with a custom Directory Opus script?

17

Hi Leo,

A common use for milliseconds in photography is so that one can rename closer-spaced shots or burst shots if one is using a time-based RENAME, without having RENAME conflicts. Even when I'm not using burst mode I sometimes trigger more than one shot a second.

18

Makes sense when renaming, but would you ever need to see that precision in a date column? It'd usually be a lot of noise.

19

Yep. even when renaming photos I'd prefer to not have the milliseconds except when a seconds-based name has conflicts.

20

In my experience, you cannot trust any Windows timestamp beyond the resolution of the OS's timeslice (~20ms). If you are creating files faster than that, you are going to be disappointed with the timestamps.

The modified timestamp on sequentially created files can easily be the same on Windows. Here are 20 files created in a row with their Modifed Timestamp as the raw value in 100ns intervals and local time:

N Field TimeStamp LocalTime
0 Modify 133610217373448322 2024.05.24 @ 10:55:37.344
1 Modify 133610217373448322 2024.05.24 @ 10:55:37.344
2 Modify 133610217373448322 2024.05.24 @ 10:55:37.344
3 Modify 133610217373448322 2024.05.24 @ 10:55:37.344
4 Modify 133610217373458297 2024.05.24 @ 10:55:37.345
5 Modify 133610217373458297 2024.05.24 @ 10:55:37.345
6 Modify 133610217373458297 2024.05.24 @ 10:55:37.345
7 Modify 133610217373458297 2024.05.24 @ 10:55:37.345
8 Modify 133610217373458297 2024.05.24 @ 10:55:37.345
9 Modify 133610217373458297 2024.05.24 @ 10:55:37.345
10 Modify 133610217373468271 2024.05.24 @ 10:55:37.346
11 Modify 133610217373468271 2024.05.24 @ 10:55:37.346
12 Modify 133610217373468271 2024.05.24 @ 10:55:37.346
13 Modify 133610217373468271 2024.05.24 @ 10:55:37.346
14 Modify 133610217373468271 2024.05.24 @ 10:55:37.346
15 Modify 133610217373478244 2024.05.24 @ 10:55:37.347
16 Modify 133610217373478244 2024.05.24 @ 10:55:37.347
17 Modify 133610217373478244 2024.05.24 @ 10:55:37.347
18 Modify 133610217373478244 2024.05.24 @ 10:55:37.347
19 Modify 133610217373478244 2024.05.24 @ 10:55:37.347

As you can see I can easily get 5 files created in a row with the exact same "100ns accurate" timestamp. Windows is just not interested in keeping a more accurate time. It certainly could get microsecond precision with the GetSystemTimePreciseAsFileTime API, but it doesn't for creating files.

Sorting those 20 files by Modified Time (newest to oldest) in Opus results in 15 being the newest. You can see that is technically correct for the 5 way tie 15-19 by looking at the raw file timestamp, but I definitely created 19 last. Opus is sorting by Modified and then by Name and if you were expecting 19 on top you would be confused.

image

Create and Access timestamps are even worse.

Create is approximately the time you created the file the first time you did it. But you can delete that file and create it again and it could have the same create time as the original file before you deleted it. Bonkers.

Access is some time after you created it. And that is about as much as you can say about it. It might be the access time. The day might be right.

I know this doesn't help you much. I would try to find a way to add a sequential number to the filename. It won't be an accurate time, but it will be unique and in the right sort order. I don't know how to do that for you though.

Another possibility, if you really care about that timestamp accuracy and have access to the filename as it is created is to write a program to rewrite the file timestamps with your own from GetSystemTimePreciseAsFileTime API.

I do support OP's request for the option for millisecond accuracy to be displayed in Opus though. I have had reason to want to know in the past. :smile: That is a long story though.