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() )
localtime(), my fmt_string was
"%Y-%m-%d %H:%M:%S", and there was no problem.
gmtime() it needed 'Z' on the end; I tried these formats and they gave correct results:
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.