<p>A note about the time zone: </p>

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

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

<p><strong>Edit</strong>: 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, <a href="https://www.cl.cam.ac.uk/~mgk25/iso-time.html" rel="nofollow noreferrer">https://www.cl.cam.ac.uk/~mgk25/iso-time.html</a>, which I think is an easier introduction than the wikipedia article (<a href="https://en.wikipedia.org/wiki/ISO_8601" rel="nofollow noreferrer">https://en.wikipedia.org/wiki/ISO_8601</a>).</p>

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

<p>Writing in Python, I tried both <strong>local</strong>: <code>time.strftime( fmt_string, time.localtime() )</code> and <strong>UTC</strong>: <code>time.strftime( fmt_string, time.gmtime() )</code></p>

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

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

<p>When I used <code>"%Y-%m-%d %H:%M:%S"</code> (without a Z) with <code>time.gmtime()</code>, the result was a <strong><em>doubling</em></strong> of the offset: At about 21h local time, the time that <code>gmtime()</code> 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.</p>

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

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

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

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

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

CC BY-SA 4.0
2019-03-27T12:05:32.287Z
2019-03-29T02:29:18.223Z
2019-03-29T02:29:18.223Z
j77h
<p>There is no standard for representation of date-time across all video formats. However, <a href="https://en.wikipedia.org/wiki/ISO_8601" rel="nofollow noreferrer">ISO 8601</a> 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.</p>

CC BY-SA 4.0
2019-01-02T07:01:38.217Z
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
CC BY-SA 4.0
2019-01-02T07:12:21.917Z
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
CC BY-SA 4.0
2019-01-02T06:45:18.310Z
2019-01-02T06:45:18.310Z
Gyan
<p>I noticed my GH5 via <code>ffprobe</code> has metadata such as:</p>

<pre><code> Metadata:
      creation_time   : 2018-12-31T09:17:48.000000Z
      timecode        : 06:19:42;19
</code></pre>

<p>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?</p>

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

<ffmpeg><h.264>
What is the correct format of media creation time?
hendry
# What is the correct format of media creation time?

(Asked by: username_0 on 2019-01-02)

I noticed my GH5 via ffprobe has metadata such as:
 Metadata:
      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}")"?

**Tags:** ffmpeg, h.264


---

## 2 answers

### Answer by username_1 on 2019-03-27. Score: 4

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.


---

### Answer by username_2 on 2019-01-02. Score: 1

There is no standard for representation of date-time across all video formats. However, [ISO 8601](https://en.wikipedia.org/wiki/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.

> **Comments:**
> **username_0**: 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.  
> **username_2**: 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.  

---

