Quoting Marton Balint (2021-05-10 19:36:59) > > > On Mon, 10 May 2021, Anton Khirnov wrote: > > > Export them in UTC, not the local timezone. This way the output is > > the same everywhere. The timezone information stored in the file is > > still ignored, since there seems to be no simple way to export it > > correctly. > > > > Format them according to ISO 8601, which we generally use for exporting > > dates. > > --- > > If anyone has practical suggestions for exporting the timezone, I would > > love to hear them. Don't see anything in the standard library for > > "express this UTC timestamp in a given timezone". Just adding the offset > > to the timestamp would AFAIU not be correct wrt leap seconds (and maybe > > something else? dates are hard). > > > > Also, the conversion of double to time_t is potentially UB if the source > > value is out of range, but there seems to be no standard way to check, > > since the range of time_t is not standard either. Anyone got any ideas? > > --- > > libavformat/flvdec.c | 7 +++++-- > > tests/ref/fate/flv-demux | 2 +- > > 2 files changed, 6 insertions(+), 3 deletions(-) > > > > diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c > > index e6c2877a74..ddaceaafe4 100644 > > --- a/libavformat/flvdec.c > > +++ b/libavformat/flvdec.c > > @@ -686,8 +686,11 @@ static int amf_parse_object(AVFormatContext *s, > > AVStream *astream, > > struct tm t; > > char datestr[128]; > > time = date.milliseconds / 1000; // to seconds > > - localtime_r(&time, &t); > > - strftime(datestr, sizeof(datestr), "%a, %d %b %Y %H:%M:%S %z", > > &t); > > + gmtime_r(&time, &t); > > + > > + // timezone is ignored, since there is no easy way to offset > > the UTC > > + // timestamp into the specified timezone > > + strftime(datestr, sizeof(datestr), "%Y-%m-%dT%H:%M:%SZ", &t); > > > > av_dict_set(&s->metadata, key, datestr, 0); > > Maybe avpriv_dict_set_timestamp() should be used instead. That way > milisecond precision can also be respected.
Huh, I did not know about that function. But since we are converting from double, I am somewhat concerned about the result remaining the same on all platforms (which is the point of this patch). -- Anton Khirnov _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
