Get creation time of file in milliseconds

13

6

Is there a way to get the creation time of a file in windows in a higher accuracy? I want to get the creation time of an mp4-video in milliseconds. Is this possible?

Phil

Posted 2015-07-07T14:09:49.747

Reputation: 143

I have to ask why you need this accuracy? – Moab – 2015-07-07T14:10:40.200

1I record some sensor data on an Android device together with a video. I wrote the sensor logging by myself and log the system time together with each sensor value. For recording the video I use the standard camera activity. After sending the data to a PC I want to analyse it. For merging the video with the sensor data I have to know when the video started. Seconds are a little bit too coarse so I'm looking for a way to get a more exact starting time of the video. – Phil – 2015-07-07T14:27:18.160

3Note: if you need that kind of relationship between two data streams, it is usually essential to put a registration signal in the stream (like the old clapboards used in movies as the director calls "action". The clap was a visual cue and audio cue, allowing the two or more streams to be synced later). In some situations, the time delay between creating the file in kernel mode (and recording the timestamp) and waking up your process to let it know it has a file handle to use could actually be higher than the tolerances you have for your data. – Cort Ammon – 2015-07-07T17:20:25.757

When you copy your stuff from Android to somewhere else, make sure all the copy tools preserve timestamp precision. Note that many copy tools will make the ctime of the copy be the time it was copied. – Peter Cordes – 2015-07-07T17:42:02.023

1On windows, I'd use cygwin/mingw stat to get all 3 timestamps. Of course, that's because I normally use GNU/Linux. – Peter Cordes – 2015-07-07T17:42:47.380

@Cort Ammon I used this kind of registration signal before but I want to automate the analysing. That is why I am looking for an alternative way. I will figure out if it is accurate enough for my purpose. – Phil – 2015-07-08T07:07:43.993

@PeterCordes I didn't think of that, it seems a little more accurate than the wmic solution. Do you mind if I add it to my answer? – DavidPostill – 2015-07-08T07:11:00.050

@DavidPostill: Go right ahead. Collecting useful stuff from comments into answers makes the site better. – Peter Cordes – 2015-07-08T07:37:03.783

@Moab Sure, since you asked, I am interested in this level of accuracy because I want to get a general idea of the order that some file system events happened, from the OS's perspective. – jrh – 2018-01-03T14:54:57.990

Answers

23

Timestamp resolution

The creation timestamp of a file in windows depends on the file system:

  • FAT/VFAT has a maximum resolution of 2s

  • NTFS has a maximum resolution of 100 ns


wmic solution

You can use wmic to retrieve the file creation date to the nearest microsecond.

Example:

F:\test>wmic datafile where name="f:\\test\\test.txt" get creationdate | findstr /brc:[0-9]
20150329221650.080654+060

The creationdate 20150329221650.080654+060 is a timestamp, with the following format:

yyyymmddHHMMSS.xxxxxxsUUU

where:

  • yyyy Four-digit year (0000 through 9999).

  • mm Two-digit month (01 through 12).

  • dd Two-digit day of the month (01 through 31).

  • HH Two-digit hour of the day using the 24-hour clock (00 through 23).

  • MM Two-digit minute in the hour (00 through 59).

  • SS Two-digit number of seconds in the minute (00 through 59).

  • xxxxxx Six-digit number of microseconds in the second (000000 through 999999)

  • s Plus sign (+) or minus sign (-) to indicate a positive or negative offset from Coordinated Universal Times (UTC).

  • UUU Three-digit offset indicating the number of minutes that the originating time zone deviates from UTC.


stat solution

You can also use stat (from a cygwin or mingw installation).

Example:

DavidPostill@Hal /f/test
$ stat test.txt | grep Birth
 Birth: 2015-03-29 22:16:50.080654200 +0100

dir output for comparison

F:\test>dir /t:c test.txt
 Volume in drive F is Expansion
 Volume Serial Number is 3656-BB63

 Directory of F:\test

29/03/2015  22:16                32 test.txt
               1 File(s)             32 bytes
               0 Dir(s)  1,798,546,849,792 bytes free

Further Reading

DavidPostill

Posted 2015-07-07T14:09:49.747

Reputation: 118 938

@NateEldredge Thanks, well spotted. Answer corrected. – DavidPostill – 2015-07-07T17:16:47.317

Also "xxxxxx represents the milliseconds" is misleading as in the example you give, it appears to represent microseconds (I'm not sure what happened to the tenths of microseconds that NTFS supposedly offers). – Nate Eldredge – 2015-07-07T17:17:00.843

UTC is not a "format" and it does not stand for "Universal Time Coordinate". It certainly has nothing to do with how you render a timestamp visually. MSDN is [very] wrong (shock horror) – Lightness Races with Monica – 2015-07-07T17:59:44.673

@LightnessRacesinOrbit According to MS docs I linked to it is :/ I have clarified the answer - does it now have your approval? ;). – DavidPostill – 2015-07-07T18:01:41.493

@DavidPostill: Yarp (though I suspect they mean UTC not GMT). Here's some reading: http://www.timeanddate.com/time/aboututc.html

– Lightness Races with Monica – 2015-07-07T18:08:48.887

@LightnessRacesinOrbit GMT is correct as UUU is an offset from a time zone. GMT is a time zone and UTC is a A Standard, Not a Time Zone as your link points out ;) – DavidPostill – 2015-07-07T18:13:00.320

@DavidPostill: Er, true; leap seconds confused me ;) – Lightness Races with Monica – 2015-07-07T18:26:45.630

4A note of caution: just because a timestamps contains a high frequency digit, such as the 100 nanoseconds' digit, does not mean the clock can be used as a reliable time source at the 100ns range. It merely states that there's a lot of bits of content which is [hopefully] monotonic and roughly correlates to "real" time. – Cort Ammon – 2015-07-07T21:45:18.630

1

See msdn CIM_DATETIME: in your notation, xxxxxx is Six-digit number of microseconds in the second (000000 through 999999). Micro-, i.e. 10^-6. Of course, the first triplet represents mili- (10^-3): truncated, not rounded. The second triplet extracted represents nothing in itself... However, some wmi datetime values show the second triplet 000 always, e.g. wmic OS get LocalDateTime

– JosefZ – 2015-07-07T21:49:17.130

@JosefZ Thanks, that's a better description. I was trying to correct the rather strange MS docs which said xxxxxx was milliseconds :/ Answer clarified. – DavidPostill – 2015-07-07T21:52:09.120

1Thanks, these kind of answers is why I love stack exchange :) – Phil – 2015-07-08T07:16:03.037

Thanks for great answer! Your "maximum precision allowed by the file system." is misleading. The System allows one more digit, that is not available via wmi. – Maris B. – 2018-05-31T09:39:20.737

@MarisB. Do you have a link/reference for this claim? – DavidPostill – 2018-05-31T17:27:20.020

@DavidPostill - MSDN documentation for FILETIME structure (https://msdn.microsoft.com/en-us/library/windows/desktop/ms724284(v=vs.85).aspx). Also, I compiled example provided by Microsoft (https://msdn.microsoft.com/en-us/library/windows/desktop/ms724926(v=vs.85).aspx) and of course you can get 7 digits (3 for milli, 3 for micro, 1 for nano) instead of wmi 6 digits.

– Maris B. – 2018-06-01T07:57:52.227

@MarisB. And File Times (Windows) says "A file time is a 64-bit value that represents the number of 100-nanosecond intervals" so it it only accurate to the nearest 100 ns which I stated right at the start of my answer.

– DavidPostill – 2018-06-01T17:35:34.723

@DavidPostill - I mean this sentence "You can use wmic to retrieve the file creation date with the maximum precision allowed by the file system." ... No, you can not retrieve maximum precision using wmic. Your answer is misleading. However, it is correct about 100-ns part :) – Maris B. – 2018-06-04T12:54:18.030

1@MarisB. Ah. Answer updated. – DavidPostill – 2018-06-04T17:37:53.480

On FAT, the granularity of creation timestamps is 0.1 s but the granularity of modification timestamps is 2.0 s. https://docs.microsoft.com/en-us/windows/desktop/SysInfo/file-times

– Nayuki – 2018-12-14T21:53:04.927

1

A clever way is demonstrated here: https://stackoverflow.com/questions/5180592/showing-ntfs-timestamp-with-100-nsec-granularity

It's using VBScript to query WMI's CIM database and return the FILETIME structure associated to a file.

There are also open source tools that can inspect a media file's metadata, such as EXIFtool which is geared towards managing the metadata of media created by digital cameras.

Stavr00

Posted 2015-07-07T14:09:49.747

Reputation: 316

1

I found a way how to obtain this in Matlab:

You can use the GetFileTime function written by Jan Simon. If you don't want to compile your own mex files, you can also download the compiled files here.

It is not as exact as using wmic (only ms) but for my purpose it is suitable.

Phil

Posted 2015-07-07T14:09:49.747

Reputation: 143

-3

It depends on the file system: FAT has 2 second resolution, NTFS theoretically has 100 ns resolution, but the actual resolution is 10 ms. That said, interrupts have higher priority than disk I/O, and I'm not sure the effect write-caching has on the time stamp. Multimedia timers are optimized for accuracy, so would be the preferred way to implement timing.

You can use an existing tool such as XYplorer to view high-resolution timestamps, or XYplorer showing ms, you may prefer to write your own application. Use the File.GetCreationTime Method; it returns a DateTime Structure with Millisecond property.

DrMoishe Pippik

Posted 2015-07-07T14:09:49.747

Reputation: 13 291

1um... not to be rude, but, did you read @DavidPostill's answer? – td512 – 2015-07-07T15:14:47.570

2

"NTFS theoretically has 100 ns resolution, but the actual resolution is 10 ms" is incorrect - that link actually says "on NT FAT, create time has a resolution of 10 milliseconds". That does not mean NTFS has that resolution. You can see from my answer that on NTFS wmic shows a resolution to the nearest microsecond.

– DavidPostill – 2015-07-07T17:34:09.170

There is a difference between theoretical and maximum resolution, one indicates well the maximum resolution, the other indicates, more of an averag resolution. – Ramhound – 2015-07-07T23:40:13.257

1@DavidPostill If the clock only increments the time every 10ms, then having a datetime filed that can represent 100ns still has an accuracy of only 10ms. The typical UtcNow APIs (as opposed to high performance counters which are designed for measuring time differences) increment the time every 0.5-16ms on windows, so this answer is quite plausible. – CodesInChaos – 2015-07-08T09:46:54.863

@CodesInChaos Yes, but - "The best resource for retrieving the system time is the GetSystemTimeAsFileTime API. It is a fast access API that is able to hold sufficiently accurate (100 ns units) values in its arguments." - I don't have access to the Windows source code so I don't know what calls are used under the hood when manipulating file timestamps. We don't know what the actual resolution is - that's just guessing. – DavidPostill – 2015-07-08T09:59:10.963