18

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?

Improve this question
9
  • I have to ask why you need this accuracy?
    – Moab
    Jul 7, 2015 at 14:10
  • 1
    I 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
    Jul 7, 2015 at 14:27
  • 4
    Note: 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
    Jul 7, 2015 at 17:20
  • 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
    Jul 7, 2015 at 17:42
  • 1
    On windows, I'd use cygwin/mingw stat to get all 3 timestamps. Of course, that's because I normally use GNU/Linux.
    – Peter Cordes
    Jul 7, 2015 at 17:42

4 Answers 4

Reset to default
29

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

Improve this answer
6
  • 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
    Jul 7, 2015 at 17:17
  • 4
    A 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
    Jul 7, 2015 at 21:45
  • 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.
    May 31, 2018 at 9:39
  • @MarisB. Do you have a link/reference for this claim?
    – DavidPostill ♦
    May 31, 2018 at 17:27
  • On FAT, the granularity of creation timestamps is 0.1 s but the granularity of modification timestamps is 2.0 s. docs.microsoft.com/en-us/windows/desktop/SysInfo/file-times
    – Nayuki
    Dec 14, 2018 at 21:53
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.

Improve this answer
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.

Improve this answer
-2

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.

Improve this answer
5
  • 1
    um... not to be rude, but, did you read @DavidPostill's answer?
    – td512
    Jul 7, 2015 at 15:14
  • 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 ♦
    Jul 7, 2015 at 17:34
  • There is a difference between theoretical and maximum resolution, one indicates well the maximum resolution, the other indicates, more of an averag resolution.
    – Ramhound
    Jul 7, 2015 at 23:40
  • 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
    Jul 8, 2015 at 9:46
  • 1
    @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 ♦
    Jul 8, 2015 at 9:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.