I noticed my GH5 via ffprobe has metadata such as:

      creation_time   : 2018-12-31T09:17:48.000000Z
      timecode        : 06:19:42;19

This is actually my local time, so off that bat, the timezone of UTC is wrong IIUC. Nonetheless is there a date/time video standard format for times?

Since I am not 100% sure what format that is, or how to create it via ffmpeg. Is it -metadata creation_time="$(date -u "+%FT%T.%6NZ" -r "${input}")"?


A note about the time zone:

ffmpeg interprets the input as local time, then converts it to and stores it as UTC.

If you want to give it UTC, add 'Z' to the end; ffmpeg then accepts it as UTC and does not change it.

Edit: ffmpeg's behavior is following an ISO 8601 rule: "a date and time [without Z] is assumed to be in some local time zone. ... to indicate that a time is ... (UTC), you can append a capital letter Z ...". Source: Markus Kuhn, https://www.cl.cam.ac.uk/~mgk25/iso-time.html, which I think is an easier introduction than the wikipedia article (https://en.wikipedia.org/wiki/ISO_8601).

I discovered this while testing by encoding to mkv, then reading metadata with ffprobe.

Writing in Python, I tried both local: time.strftime( fmt_string, time.localtime() ) and UTC: time.strftime( fmt_string, time.gmtime() )

With localtime(), my fmt_string was "%Y-%m-%d %H:%M:%S", and there was no problem.

With gmtime() it needed 'Z' on the end; I tried these formats and they gave correct results: "%Y-%m-%dT%H:%M:%SZ" and "%Y%m%dT%H%M%SZ".

When I used "%Y-%m-%d %H:%M:%S" (without a Z) with time.gmtime(), the result was a doubling of the offset: At about 21h local time, the time that gmtime() produced was about 11h (I'm in AEST, 10 hours ahead of UTC); ffmpeg took this as local time and subtracted another 10 hours, so the result that ffprobe showed was around 01h.

The standard says there must not be a space before the Z, so I didn't try that.

Regardless of the input format, ffprobe always wrote creation_time formatted as in this example: "2019-03-27T03:01:29.000000Z". I don't know whether the time is stored in that format, or as a simple number such as a unix timestamp.

Note the Z on the end, which shows that ffmpeg thinks it's a UTC time.

If you write a time in another tag, such as 'comment', it's just a string and stays the way you formatted it.

Using the deprecated option -timestamp (as e.g. -timestamp now) produced a creation_time tag, which ffprobe showed in the same format as shown above.

| improve this answer | |

There is no standard for representation of date-time across all video formats. However, ISO 8601 is most commonly used (as seen in your video). Note that MP4s require that the UTC time be stored, so it's up to the MP4-creating app to convert the local time since readers have to expect only UTC. So, unless you know that, there will be uncertainty as to what the actual time is.

| improve this answer | |
  • oh, "2018-12-31T09:17:48.000000Z" didn't look quite like iso8601, hence the crazy "+%FT%T.%6NZ formatting. But if iso8601 is acceptable, I'll change my code. – hendry Jan 2 '19 at 7:01
  • MP4s save the datetime as epoch seconds internally (from 1904-01-01 00:00 UTC). It's up to the consumer app to format it for display. Most use 8601. – Gyan Jan 2 '19 at 7:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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