Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-03-27T12:05:32.287Z
Answers.LastActivityDate: 2019-03-29T02:29:18.223Z
Answers.LastEditDate: 2019-03-29T02:29:18.223Z
Answers.UserDisplayName: j77h
Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-01-02T07:01:38.217Z
Answers.Text: 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.
Answers.UserDisplayName: hendry
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-01-02T07:12:21.917Z
Answers.Text: 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.
Answers.UserDisplayName: Gyan
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-01-02T06:45:18.310Z
Answers.LastActivityDate: 2019-01-02T06:45:18.310Z
Answers.UserDisplayName: Gyan
Body: <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>
  
Tags: <ffmpeg><h.264>
Title: What is the correct format of media creation time?
UserDisplayName: hendry
ThreadText: # 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.  
  
  ---
  
  