Proposal: rounding method & total method for Duration type

[justingrant]

This proposal:

• Extends the Temporal.Duration type with a new method (called round() as a placeholder) to perform balancing and rounding.
• Adds a new total(unit, options) method on Duration to handle common use cases that are difficult to accommodate into a balanced method.
• Adds new options (same as on round) to non-Duration types' difference methods.
• Adds a new round method to non-Duration types to support rounding of those types, using similar options as round on Duration.

This proposal fleshes out ideas previously discussed in #337 and #584, and discussed at length between @sffc, @jasonwilliams, and @justingrant at the 2020-07-23 champions meeting.

Use Cases

Common Use Cases (we probably want API support for these)

• Normalization of existing durations, e.g. PT130M => PT2H10M
• Rounding to nearest, e.g. PT10M52S => PT11M
• Rounding up, e.g. PT10M52S => PT11M
• Truncation (rounding towards zero), e.g. PT10M52S => PT10M
• Format a duration in a normalized text format
• Calculating totals (e.g. how many total seconds in PT2H34M18S)
  • ISSUE: currently, largestUnit is limited to seconds or larger, so calculating total ms/microsecs/ns is hard
• Normalization that takes DST into account, e.g. convert PT1756H into days, assuming starting at midnight on a day that DST ends.
• Normalization that ignores DST and treats every day as 24 hours.
• Normalize days into months/years, e.g. P190D -> P6M12D (requires knowing the starting point and, optionally, the calendar)

Less Common Use Cases (may choose to not offer API support for these if supporting them makes common use cases more complex)

• Non-ISO calendar-aware normalization of days into weeks & months
• Fractional remainders, e.g. "How many days are in 36 hours?" => 1.5 days.
• Rounding to multiples of a unit, e.g. round to nearest 15 minutes or truncate to integer number of 3-month quarters
• "Get Remainder" / Top-end truncation, e.g. get time-only portion of a Duration, or fetch fractional seconds units.
• Get a date-only or time-only portion of a duration. The former is easy today via {largestUnit: 'days'}. The latter is really just a special case of the "Get Remainder" case above.
• "Disjoint units" - some platforms store date/time values as a tuple of a "large" and "small" unit, where "large" is typically a day and "small" is usually the smallest unit of supported precision. For example, SQL Server's legacy date/time types:

  Values with the datetime data type are stored internally by the SQL Server 2005 Database Engine as two 4-byte integers. The first 4 bytes store the number of days before or after the base date: January 1, 1900. The base date is the system reference date. The other 4 bytes store the time of day represented as the number of 1/300-second units after midnight.

  The smalldatetime data type stores dates and times of day with less precision than datetime. The Database Engine stores smalldatetime values as two 2-byte integers. The first 2 bytes store the number of days after January 1, 1900. The other 2 bytes store the number of minutes since midnight.

Challenges / Notes

Below is a summary of problems discussed in the 2020-07-23 champions meeting. This list is likely incomplete, but all of the items below are addressed in this proposal.

• Normalizing across time/date boundary requires a starting point and time zone
• Normalizing across day/month boundary requires a starting point and calendar
• What should be default (e.g. calendar, or UTC)?
• Do we optimize ergonomics for the case where smallestUnit === largestUnit?
• What balancing options should be available on plus/minus?
  • Ideally, users wouldn't have to learn different ways to specify balancing options in a dedicated method vs. in minus
  • With negative durations, minus and plus must accept the same options
• Should balancing be part of from/with?
• Defaults
  • largestUnit
  • smallestUnit - nanoseconds
  • starting point
  • choice 1: No default. Will throw if needed.
  • choice 2: 24-hour days
• Is there a “30-day-month” default possible? (e.g. custom calendar with 30-day months)
• How can weeks and months coexist in a balanced duration?

Proposal

1. The Duration type will add a new prototype method for rounding and balancing. For purposes of this proposal we'll call it round as a placeholder, but we'll probably want to bikeshed on the name.

• 1.1 Some possible names to start the bikeshed: balanced, adjusted ,normalized, transformed, reshaped, adapted, conformed.
• 1.2 One gotcha for naming: balancing only applies to Duration, but this method will also do rounding, which does apply to other types, e.g. "Round the current time to the nearest hour". Therefore, if we want to offer the same-named method on both Duration and non-Duration types, then balanced wouldn't be a good name and something more generic, e.g. adjusted or normalized would make more sense. See (12) below for more discussion.

2. This method will have only one optional parameter: an options bag. Options should do the following things:

• 2.1 Control which units are returned in the result, both the largest and the smallest unit.
  • 2.1.1 The most common case is for the largest and smallest units to be a contiguous range
  • 2.1.2 Another common use case for the largest and smallest unit to be the same, e.g. for the "total seconds in this duration" use case. We may want to provide ergonomic support for this use case.
  • 2.1.3 An uncommon case is the "disjoint units" use case noted above, e.g. transform a Duration into a number of days and a number of nanoseconds remainder in the final day. It's not clear that this case is common enough to deserve dedicated API support.
• 2.2 Control rounding at the low end. We should use the same rounding modes used by Decimal and by Intl.NumberFormat (tc39/proposal-intl-numberformat-v3#7).
• 2.3 Define the starting point used when balancing across an hours/days boundary (where an Absolute+TimeZone is needed in case there's a DST transition) or a days/months boundary (where an Absolute+TimeZone+Calendar or a DateTime+Calendar is needed because months are different lengths).
• 2.4 Some (all?) options in the new method will also be needed for use with Duration.prototype.minus and Duration.prototype.plus (remember that plus with negative durations is the same as minus). When designing the options for the new balancing method, we should keep plus/minus in mind to ensure consistency.
• 2.6 The sections below outline each option.

3. smallestUnit / largestUnit options

• 3.1 The largestUnit property acts like it does in other types' difference methods.
• 3.2 The smallestUnit property defines where rounding happens. All smaller units will be zero in the result.
• 3.3 If smallestUnit is larger than largestUnit, then a RangeError should be thrown.
• 3.4 Although there are reasons (see below) for a dedicated total method, a simple "total of one unit" use case is supported by supplying the same unit name for both largestUnit and smallestUnit.

  d.round({ largestUnit: 'days', smallestUnit: 'minutes' };
  d.round({ largestUnit: 'days' };
  d.round({ smallestUnit: 'minutes' };
  d.round({ largestUnit: 'seconds', smallestUnit: 'seconds' };

• 3.5 The "disjoint units" use case is not supported directly by these options.
• 3.6 The default for smallestUnit / largestUnit options depends on the relativeTo option (see below).

4. relativeTo option

• 4.1 This option defines a date/time value (with accompanying time zone and/or calendar) that balancing should be relative to. For example, a P40D would balance to P1M11D if the starting point is 2020-02-01.
• 4.2 This option, if not omitted, can either be a Temporal.LocalDateTime instance (for date/time balancing) or a Temporal.Date instance (for date-only balancing).
  • 4.2.1 If this option is undefined or omitted then smallestUnit should default to 'nanoseconds' and largestUnit should default to 'hours'. This is like current Duration behavior, except days and weeks are not supported.
  • 4.2.1.1 If this option is undefined or omitted and largestUnit is 'days' or larger, a RangeError should be thrown.
  • 4.2.2 If a LocalDateTime instance is used, then smallestUnit should default to 'nanoseconds' and largestUnit should default to years.
  • 4.2.3 If a Date instance is used, then smallestUnit should default to 'days' and 'largestUnit' should default to 'years'.
  • 4.2.3.1 If a Date instance is used, the method should throw if the user provides a smallestUnit smaller than 'days'.
  • 4.2.4 TODO: Balancing date/time durations with largestUnit: 'days' or largestUnit: 'weeks' where 24-hour-day, ignore-DST behavior is desired will be a common use case. It's a PITA to have to create a dummy LocalDateTime instance in UTC tim zone just to get that behavior. Should there be an ergonomic shortcut value for relativeTo that would enable that case, e.g. null or a literal string like 'utc'?
• 4.3 Note that the dependency above implies that we'd have to merge this proposal after LocalDateTime is merged.
• 4.4 Another solution considered was allowing separate Absolute, TimeZone, and/or DateTime options. This seems unnecessarily complex relative to simply requiring a single LocalDateTime or a Date value.
• 4.5 @sffc noted a case where users may want to assume 30-day months to avoid specifying a start date. This case will be supported via docs; users can set largestUnit: 'days' and then they can manually convert to months as needed.
• 4.6 Alternate names to relativeTo include: start, startFrom, startingPoint. I prefer relativeTo because it feels more unidirectional while start* might be ambiguous when working with a negative duration. Feel free to suggest something better.
• 4.7 If largestUnit is 'days' or larger, then relativeTo is required. Otherwise it's ignored.
  • 4.7.1 In theory, relativeTo is only needed for balancing across the hours/days, days/months, or months/years boundaries, so we could only require it for values that cause an overflow to a larger unit. But IMHO it seems brittle to vary behavior based on the magnitude of this, because failures might only happen in production after some threshold is reached, e.g. 24 hours of gameplay. Instead, I think the better approach is to require a starting point based only on the unit options provided.

5. Rounding option(s?)

• 5.1 This option defines how the remainder is handled: e.g. round up, round down, round to nearest, etc. There are a surprisingly large number of possible rounding modes (e.g. round down vs. round towards zero for negative numbers, how to handle 0.5 remainders, etc.).
  • 5.1.1 There are two other potential users of rounding modes in JS: the Decimal proposal and Intl.NumberFormat V3. IMHO, Temporal should follow the lead of one of those other two proposals in terms of naming and modes available, so that all of JS would have consistent rounding. So any discussion of naming below should be considered feedback into those other two proposals rather than a definite decision for Temporal.
  • 5.1.1.1 Per @sffc, NumberFormat V3 is the furthest ahead of all three proposals so we'll tentatively plan for the naming and rounding-mode decisions to be made there first.
• 5.2 Possible option names include (pending alignment with those other proposals): "rounding", "roundingMode", "roundingType", "roundingMethod". I prefer "rounding" because it's short.
• 5.3 For naming the option strings themselves, my recommendation would be to align with Math methods: 'ceil', 'floor', and 'trunc'. This will both be familiar to users and will avoid ambiguity from using words like "up" or "largest" when using negative durations. For rounding-to-nearest, see https://github.com/tc39/proposal-intl-numberformat-v3/issues/7#issuecomment-664717034 for a discussion of naming challenges. Regardless, we should follow Decimal/Intl's lead if they choose different names.
• 5.4 If Duration supported fractional values on its smallest unit (like ISO 8601 does) then we'd also want a "none" (or "float" or "decimal" or "remainder" or "fractional") choice that doesn't do any rounding but instead calculates a fractional remainder value and returns a floating-point number as the lowest unit? But Duration only supports integer fields, so the result would have to be a Duration-like property bag, not a Duration instance, which IMHO would be very confusing. But this is still a valid use case. My suggestion would be to offer a separate total method which could support this. See below.
  • 5.4.1 FWIW, ISO 8601 allows the smallest unit to have a fractional part, so if we offer this option on balancing, should we also offer it on Duration.prototype.toString()
• 5.5 Do we want to offer a "multi-unit" rounding, e.g. "nearest 15 minutes", "number of quarters (3-month periods)"? If yes, two possible syntaxes are below. I prefer the former for clarity and for better IDE discoverability.

  // round up to next 15-minute
  d.round({ smallestUnit: 'minutes', rounding: 'ceil' });
  d.round({ smallestUnit: 'minutes', rounding: 'ceil', roundingIncrement: 15 });
  // OR
  d.round({ smallestUnit: 'minutes', rounding: 'ceil' });
  d.round({ smallestUnit: 'minutes', rounding: { ceil: 15 });

  • 5.5.1 If we offer this kind of option, then @sffc suggested (and I agree) that we should limit increments to even multiples of the next largest unit: "For example, if smallestUnit is minutes, then roundingIncrement can be either 1 (default), 2, 3, 4, 5, 6, 10, 12, 15, 20, or 30.". Note that some units have variable length (e.g. months, or days in DST-using time zones, or years in some non-ISO calendars) so this option may only be useful for seconds, minutes, and perhaps months (if calendar is always 12 months) and hours (if time zone is UTC). Given that the primary use cases for this feature is going to be minute increments, seconds increments, and 3-month quarters, these limits may be OK. But it's worth discussing.
  • 5.5.2 Like with rounding modes, if we offer this kind of option, then we should align naming and behavior with planned NumberFormat v3. Temporal should follow Intl's lead.

6. Weeks vs. Days/Months

• 6.1 Weeks overlap with days and months in a duration. While there may be some cases where users might want weeks together with months and/or days (e.g. "3 months, 2 weeks, and 4 days") that's an uncommon case relative to the "3 months and 18 days" result that is likely expected.
• 6.2 We'll handle these cases by setting weeks to zero when there's potential ambiguity between weeks vs. days/months. Specifically: if largestUnit is 'months' or 'years' and smallestUnit is 'days' or smaller, then weeks will always be zero and only days and/or months will be included in the result. Edge cases that are NOT ambiguous are noted below.
  • 6.2.1 If smallestUnit is 'weeks', then there is no ambiguity and any remainder will go into weeks.
  • 6.2.2 If largestUnit is 'days', then there is no ambiguity because weeks are excluded and weeks will be zero.
  • 6.2.3 In the degenerate case of { largestUnit: 'weeks', smallestUnit: 'days' } then there is also no ambiguity so both fields will be populated.

7. Remainder-only option?

• 7.1 Some use cases (e.g. time-only portion of a duration, or fetching all sub-second units) are similar to balancing but instead of balancing larger units down to largestUnit, those use cases simply want to truncate some larger units. I've not been able to figure out a good solution to these use cases within the round API, and given these use cases' lower priority I'm not sure they need API support. Feel free to suggest ideas.

8. Usage in Duration.prototype.plus and Duration.prototype.minus

• 8.1 Duration subtraction requires, at a minimum, the balanceConstrain option because mixed-sign units are not supported, even with negative durations. Therefore, plus and minus will be extended to support all options allowed for round.
  • 8.2.1 The alternative would be to only support the relativeTo option, which is the only balancing option that is strictly required for duration arithmetic. But IMHO it'd be clearer and more consistent to allow all balancing options in plus/minus, as opposed to just cherry-picking some options but not others.
• 8.2 With negative durations, both plus and minus must support the same options (#645). I think the cleanest and most consistent way to support this alignment would be to offer disambiguation option values of constrain, balance, and reject.
  • 8.2.1 For subtraction operations, constrain would act like balanceConstrain does today. Note that this is a breaking change to current API.
• 8.3 The relativeTo option is potentially ambiguous. For example, when adding PT30D and PT60D, is relativeTo mean the instant before the first Duration, or the instant after the first Duration but before the second duration?
  • 8.3.1 To resolve this ambiguity, we'll define relativeTo to the former meaning: the instant before the first duration is applied. There are two reasons to use this default: 1) it matches how relativeTo will be used in the round method. 2) It enables 3+ durations to be summed while using the same relativeTo value for each call.

9. total method for Duration type

• 9.1 A very common use case is to want to calculate a duration in terms of one single unit, e.g. "total days" or "total seconds". While a solution to this case is available by setting largestUnit to the same as smallestUnit, this solution isn't very discoverable nor ergonomic.
• 9.2 Therefore, my recommendation is to offer a dedicated total method that takes a required unit: string parameter and an optional options parameter.
• 9.3 The options parameter should only accept the relativeTo and rounding options.
  • 9.3.1 relativeTo should default to undefined for totalHours() and smaller units' methods
  • 9.3.2 relativeTo should be required (no default) for totalDays() and larger units' methods.
  • 9.3.3 rounding should default to whatever the default chosen in Intl.NumberFormatV3.

10. Should we offer timePortion, datePortion properties? * 10.1 RFC 5545 durations always require splitting the date and time portions of a duration. It may be helpful to provide convenience properties for these use cases, e.g. Duration.prototype.datePortion and Duration.prototype.timePortion.

11. Should balancing be removed from Duration's from and with?

• 11.1 Once we have a dedicated round method, should we retain balancing in from and with? Given that we have to have balancing in plus and minus, IMHO it seems most consistent to leave balancing in from and with too.
• 11.2 Previously in #609 (fixed by #642), we removed balancing from non-Duration types because it wasn't needed. But with Duration, balancing is inherently required, so there's not the same value in removing balancing.
• 11.3 Unlike other types, the ISO 8601 persistence format may require balancing, so it makes sense to offer balancing as part of from.
• 11.4 TL;DR - I think we should keep balancing in these methods, and we should support all the options (with the same behavior) as the round method offers.

12. Rounding for non-Duration Temporal types

• 12.1 Although balancing doesn't apply to other Temporal types, rounding absolutely does, and for very common use cases, e.g. :
  • 12.1.1 "Round the current time to the nearest 5 minutes"
  • 12.1.2 "What's the closest Saturday to this Date?"
  • 12.1.3 "Remove the seconds and smaller units from this Time"
  • 12.1.4 "Round this time to the nearest second".
  • 12.1.5 "What was the first day of this calendar quarter?"
• 12.2 Therefore, we'll add a round method on non-Duration types
• 12.3 This method would only accept a subset of options as the Duration method: smallestUnit and any other rounding options (e.g. mode, increment, etc.). relativeTo and largestUnit would be ignored.
• 12.4 The default for smallestUnit would be the smallest unit of the underlying type.
• 12.5 We should accept both plural and non-plural unit names because non-Duration types' fields aren't pluralized. This may be a reason to accept either plural or non-plural names in other places too. See #325.

13. Balancing in non-Duration difference methods

• 13.1 Currently, difference methods throughout Temporal accept a largestUnit option.
• 13.2 To maintain consistent behavior across Temporal, as part of this proposal we'd enhance these methods to also accept the new options in this proposal (smallestUnit, relativeTo, rounding, etc.).

[sffc]

2.2 Control rounding at the low end. Rounding types include: nearest; floor (round towards zero); ceiling (round up; away from zero).

We should probably use rounding modes: https://github.com/tc39/proposal-intl-numberformat-v3/issues/7

4.5 @sffc noted a case where users may want to assume 30-day months to avoid specifying a start date. Should we support this case via a custom calendar? IMHO this would be confusing because how would months roll up into years? Instead, I think a reasonable solution for this case is having users set largestUnit: 'days' and then manually convert to months as needed.

SGTM

4.7 If largestUnit is 'days' or larger, then relativeTo is required. Otherwise it's ignored.

But you also said that an undefined relativeTo implies largestUnit="days"?

5.6 Do we want to offer a "multi-unit" rounding, e.g. "nearest 15 minutes", "number of quarters (3-month periods)"? If yes, two possible syntaxes are below. I prefer the former for clarity and for better IDE discoverability.

Rounding increments are tricky. I have some related ideas sketched out in https://github.com/tc39/proposal-intl-numberformat-v3/issues/8#issuecomment-619304130.

For example, what should be the result of balancing PT400M with an interval of 25 minutes?

I'm convinced that the only sane way to do rounding increments is for the increments to be even divisions of the greater unit. In my NumberFormat V3 proposal above, I restricted the increment to either 5 or 10 in a base-10 system. In the Temporal.Duration case, maybe we can either say that the increments need to be evenly divisible, or explicitly list out all of the allowed increments. For example, if smallestUnit is minutes, then roundingIncrement can be either 1 (default), 2, 3, 4, 5, 6, 10, 12, 15, 20, or 30.

Note: I am not expressing an opinion one way or another on whether to include this option.

6.2 We'll use the largestUnit option for this purpose. If largestUnit is 'months' or 'years', then weeks will be zero in the result and the remainder days will be put into the days property.

Right; what happens in the edge case where smallestUnit='weeks' and largestUnit='months'?

The rest pretty much looks good to me. Thanks for the detailed write-up!

[justingrant]

Thanks @sffc for this thorough review. I agree with all your feedback and I updated the proposal accordingly.

But you also said that an undefined relativeTo implies largestUnit="days"?

Shoot, you're right. I reworked section 4.7 to change the default largestUnit to 'hours', which makes the default balancing DST-safe and fixes the contradiction you found.

Right; what happens in the edge case where smallestUnit='weeks' and largestUnit='months'?

Good point. I think "weeks" should be included in that case. I reworked section 6.2 accordingly. Please review.

I'm convinced that the only sane way to do rounding increments is for the increments to be even divisions of the greater unit.

SGTM. There's an added wrinkle in that the # of hours per day is timezone-dependent and the number of months per year is calendar-dependent. I rewrote section 5.6 to address this. Let me know what you think.

We should probably use rounding modes: tc39/proposal-intl-numberformat-v3#7

Agreed. I updated the spec throughout to say that Temporal should follow the lead of Intl and/or Decimal.

When it comes to rounding modes, I assume that Temporal will use the other proposals' naming and modes, except that IMHO the default should be "truncate" for Temporal. See updated section 5.6.

A general concern: I strongly agree with you that Temporal should align with rounding options used in other JS proposals, but what are the timelines of Decimal and NumberFormat v3? Which is ahead? Could we be blocked (or could we block those other proposals) while we wait for all three to having options naming & shape finalized?

P.S. - I also thought through the impact on non-Duration types and added sections 12 (to add a rounding method to non-Duration types) and 13 (for difference options). LMK what you think.

[sffc]

what are the timelines of Decimal and NumberFormat v3? Which is ahead? Could we be blocked (or could we block those other proposals) while we wait for all three to having options naming & shape finalized?

I think whichever proposal progresses first will be the one that decides the terminology. But, I'm hoping to advance Intl.NumberFormat v3 in either September or November. Decimal is still a ways off.

12. Rounding for non-Duration Temporal types

I think this has been brought up before, but we didn't have a concrete proposal for it, so it was never acted upon. Now that we have something to work off of, I agree that this seems like a good thing to do.

12.5 We should probably accept non-plural naming of units because non-Duration types' fields aren't pluralized.

325

[sffc]

Can you double-check the new section 6.2? It doesn't seem to address { smallestUnit: "weeks", largestUnit: "months" }.

[justingrant]

I think whichever proposal progresses first will be the one that decides the terminology. But, I'm hoping to advance Intl.NumberFormat v3 in either September or November. Decimal is still a ways off.

OK sounds good. I left feedback about naming in https://github.com/tc39/proposal-intl-numberformat-v3/issues/7#issuecomment-664717034

Can you double-check the new section 6.2? It doesn't seem to address { smallestUnit: "weeks", largestUnit: "months" }.

Hmm, not sure if the problem is my unclear text but correct solution, or unclear clear text and wrong solution. ;-) Let's see if we can figure out which is the case. Here's how I was thinking it'd work:

const dur60 = Temporal.Duration.from('P60D');
const dur61 = Temporal.Duration.from('P61D');
dur60.balanced({ 
  relativeTo: Temporal.Date.from({ year: 2020, month: 1, day: 1 }), 
  smallestUnit: 'weeks', 
  largestUnit: 'months',
  rounding: 'ciel'
});
// => P2M (no remainder; 60 days = 31 + 29 = 2 months exactly ) 
dur61.balanced({ 
  relativeTo: Temporal.Date.from({ year: 2020, month: 1, day: 1 }), 
  smallestUnit: 'weeks', 
  largestUnit: 'months',
  rounding: 'ciel'
});
// => P2M1W  (extra remainder day rounded up to 1 week)
dur61.balanced({ 
  relativeTo: Temporal.Date.from({ year: 2020, month: 1, day: 1 }), 
  smallestUnit: 'weeks', 
  largestUnit: 'months',
  rounding: 'trunc'
});
// => P2M  (extra remainder day is truncated)

Does this behavior seem correct? If so, how would you recommend changing 6.2 to clarify? If not, what do you think would be correct behavior?

BTW, one thing I noticed looking at the sample was lousy ergonomics in the case where largestUnit is days and the Duration has both a date and a time portion. So I added a new section:

• 4.2.4 TODO: Balancing date/time durations with largestUnit: 'days' or largestUnit: 'weeks' where 24-hour-day, ignore-DST behavior is desired will be a common use case. It's a PITA to have to create a dummy LocalDateTime instance in UTC tim zone just to get that behavior. Should there be an ergonomic shortcut value for relativeTo that would enable that case, e.g. null or a literal string like 'utc'?

[justingrant]

Decisions 2020-07-31: 1) Add a round method to non-Duration types 2) Add rounding capabilities to non-Duration difference methods 3) Match Intl.NumberFormat V3 for rounding modes (including naming) 4) No consensus on rounding and balancing method on the Duration method. Need more discussion.

We'll move forward on 1-3 and do more discussion on 4.

[justingrant]

I updated the proposal text to match the decisions above. It may make sense to split this proposal into two pieces: one piece for rounding in round and difference of non-Duration types (which has consensus support), and a second part to deal with changes on the Duration type itself.

[justingrant]

Following up from our 2020-07-31 meeting, I moved the parts of this issue that had consensus (the parts focused on rounding for non-Duration types) into a new proposal: #827. Next, I'll revise this proposal to shrink its scope to focus only on the Duration type. This will hopefully help us resolve open issues more easily with a smaller scope.

[justingrant]

This proposal is now split in two:

• The non-Duration parts now live in #827.
• The Duration parts now live in #856. This proposal depends on #827 so please review #827 first.

I'm going to close this issue. Please add your feedback to those other two issues.