-
Notifications
You must be signed in to change notification settings - Fork 9.1k
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
Conversation
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
@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 |
On Wed, May 06, 2015 at 11:29:08PM -0700, Ron wrote:
The one-liner difference between a PR and an issue seemed small enough
Absolutely, and I've gone ahead and used my suggestions in my personal
Can't we do that with the PR? I'm happy to open new issues, but I |
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. |
On Thu, May 07, 2015 at 09:28:14AM -0700, Ron wrote:
Huh. I'm surprised, but I guess there's no arguing with a measurable |
Thank you for creating the issues :) |
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:
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:
explicit units:
and
[{day}.]{hour}:{minute}[:{second}[.{fraction}]]
strings: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.