Support timezones in ISO8601 timestamps obtained from DASH UTCTiming elements

[pstambrecht]

DashMediaSource class supports only "yyyy-MM-dd'T'HH:mm:ss'Z'" date format. Only one way how to change it is implement own custom DashMediaSource class. 806 lines of implementation for 1 line change. What about enable custom date format?

private static final class Iso8601Parser implements ParsingLoadable.Parser<Long> {

    @Override
    public Long parse(Uri uri, InputStream inputStream) throws IOException {
      String firstLine = new BufferedReader(new InputStreamReader(inputStream)).readLine();
      try {
        // TODO: It may be necessary to handle timestamp offsets from UTC.
        SimpleDateFormat format = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss'Z'", Locale.US);
        format.setTimeZone(TimeZone.getTimeZone("UTC"));
        return format.parse(firstLine).getTime();
      } catch (ParseException e) {
        throw new ParserException(e);
      }
    }

  }

[ojw28]

Please provide an example of a standard compliant DASH manifest containing a date in a format that our parser doesn't handle. Thanks.

[pstambrecht]

In .mpd file is
<UTCTiming schemeIdUri="urn:mpeg:dash:utc:http-iso:2014" value="https://st14-4.o2tv.cz:443/get-utc-timestamp"/>

which contains URL to https://st14-4.o2tv.cz:443/get-utc-timestamp . This URL returns time in yyyy-MM-dd'T'HH:mm:ssXXX format.

[ojw28]

The format looks like: yyyy-MM-dd'T'HH:mm:ss<timezone-designator> to me, so this is really a request to implement the TODO in the code you reference:

// TODO: It may be necessary to handle timestamp offsets from UTC.

In this specific case the timezone looks like it's set to 0 currently, which is the same as Z, which is therefore trivial to handle. It's unclear whether your server will ever return a non-zero timezone, however. In the general case we need to handle timezones as specified here.

If you need this functionality, perhaps you could send a pull request to our dev-v2 branch that does the TODO?

[ojw28]

Note that if you know the timezone is always going to be 0, then you could add partial support sufficient for your use case simply by checking whether firstLine ends with "+00:00", "+0000" or "+00", and replacing with "Z" if so before parsing.

[pstambrecht]

Pull request ready.... #3545

[ojw28]

Request merged, thanks! Leaving this open. We have a change that adds more comprehensive timezone support that we'll merge fairly soon, at which point this can be closed.

[pstambrecht]

You're welcome :)