Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

versions/2.0: Add a 'duration' format #356

Closed
wants to merge 1 commit into from

Conversation

wking
Copy link

@wking wking commented May 6, 2015

On IRC today, Tony Tam pointed out that folks currently work around
the lack of durations by using an int64 for millisecond offsets, but
that's not very human readable. And we care about human-readability
or we'd all be using protobufs instead of JSON, right? ;).

The support for ISO 8601 durations in native JavaScript is
unclear, but both Firefox 31.5 and Chromium 41.0 give:

> new Date('P3D')
Invalid Date

So the millisecond approach may be easier to use in JavaScript
applications, where date-times are stored as millisecond offsets from
the epoch
, you can instantiate Dates from those millisecond
offsets
, and durations are in milliseconds by default.

The Moment.js library supports durations based on millisecond offsets:

moment.duration(100);

explicit units:

moment.duration(2, 'seconds');

and [{day}.]{hour}:{minute}[:{second}[.{fraction}]] strings:

moment.duration('23:59');
moment.duration('23:59:59');
moment.duration('23:59:59.999');
moment.duration('7.23:59:59.999');

And it renders ISO 8601 durations, but it
doesn't appear to parse that format.

Java parses ISO 8601 durations with an extension to support negative
durations
.

Go parses durations from its own format.

Python has a duration type, but does not parse ISO 8601 durations.

On IRC today, Tony Tam pointed out that folks currently work around
the lack of durations by using an int64 for millisecond offsets, but
that's not very human readable.  And we care about human-readability
or we'd all be using protobufs instead of JSON, right?  ;).

The support for ISO 8601 durations [1,2] in native JavaScript is
unclear, but both Firefox 31.5 and Chromium 41.0 give:

  > new Date('P3D')
  Invalid Date

So the millisecond approach may be easier to use in JavaScript
applications, where date-times are stored as millisecond offsets from
the epoch [3], you can instantiate Dates from those millisecond
offsets [4], and durations are in milliseconds by default [5].

The Moment.js library supports durations based on millisecond offsets
[6]:

  moment.duration(100);

explicit units:

  moment.duration(2, 'seconds');

and [{day}.]{hour}:{minute}[:{second}[.{fraction}]] strings:

  moment.duration('23:59');
  moment.duration('23:59:59');
  moment.duration('23:59:59.999');
  moment.duration('7.23:59:59.999');

And it renders ISO 8601 durations [7], but it doesn't appear to parse
that format.

Java parses ISO 8601 durations with an extension to support negative
durations [8].

Go parses durations from its own format [9].

Python has a duration type, but does not parse ISO 8601 durations
[10].

[1]: http://xml2rfc.ietf.org/public/rfc/html/rfc3339.html#iso.8601.collected.abnf
[2]: http://en.wikipedia.org/wiki/ISO_8601#Durations
[3]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date#Description
[4]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date#Syntax
[5]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date#Example:_Calculating_elapsed_time
[6]: http://momentjs.com/docs/#/durations/creating/
[7]: http://momentjs.com/docs/#/durations/as-json/
[8]: https://docs.oracle.com/javase/8/docs/api/java/time/Duration.html#parse-java.lang.CharSequence-
[9]: http://golang.org/pkg/time/#ParseDuration
[10]: https://docs.python.org/3/library/datetime.html#timedelta-objects
@webron
Copy link
Member

webron commented May 7, 2015

@wking - I'm sorry, but Tony said you should open an issue, not submit a PR... we're not changing the current spec, but it can definitely be a suggestion for the next version. Keep in mind that format is a free form field and is not restricted to the values in the spec itself. Please resubmit it as a feature request and I'll label it to be taken into account for the next version of the spec.

@webron webron closed this May 7, 2015
@wking
Copy link
Author

wking commented May 7, 2015

On Wed, May 06, 2015 at 11:29:08PM -0700, Ron wrote:

@wking - I'm sorry, but Tony said you should open an issue, not
submit a PR... we're not changing the current spec, but it can
definitely be a suggestion for the next version.

The one-liner difference between a PR and an issue seemed small enough
that I might as well make it a PR ;). I'm happy to resubmit against
the v3 spec once you have a branch to rebase onto.

Keep in mind that format is a free form field and is not
restricted to the values in the spec itself.

Absolutely, and I've gone ahead and used my suggestions in my personal
spec. But having a standardized, consensus approach makes interop
easier, so I thought it was worth rolling these into the official
spec (v3 is fine).

Please resubmit it as a feature request and I'll label it to be
taken into account for the next version of the spec.

Can't we do that with the PR? I'm happy to open new issues, but I
don't understand the difference between an issue and a PR in this
context (both can be opened, closed, and organize discussion).

@webron
Copy link
Member

webron commented May 7, 2015

PRs are made against content of the existing files in the repository. Considering the next version (whichever it may be) is probably going to be written from scratch, a PR is not relevant since the file itself is not yet available.

People do not tend to comment on PRs. Issues are the common platform to induce discussions whether it's a small suggestion or a big one.

I agree that the change you suggest here is small (and very much appreciated), but we have a process we're trying to keep. The PR will end up getting lost and not take part of the actual process, which is definitely not what we'd want to achieve.

@wking
Copy link
Author

wking commented May 7, 2015

On Thu, May 07, 2015 at 09:28:14AM -0700, Ron wrote:

People do not tend to comment on PRs.

Huh. I'm surprised, but I guess there's no arguing with a measurable
trend. Issues created.

@webron
Copy link
Member

webron commented May 10, 2015

Thank you for creating the issues :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants