Why do toString methods truncate? #329
Comments
|
I'll add that js-joda (which is just a port of JSR-310, Java's newer date/time implementation which is similar to Temporal) does the same: > require('@js-joda/core').ZonedDateTime.parse('1970-01-01T00:00:00.000Z').toString()
'1970-01-01T00:00Z'My guess is that since seconds are optional by the standard, they strive for the most compact representation, but it does annoy me that it breaks sorting and a lot of incomplete ISO date parsing implementations. One example is SQL Server which doesn't accept such strings as proper dates, and debugging this could be a bit of a nightmare depending on the situation. |
|
Discussion Summary: we need both behaviours that are chosen via a parameter that gives the smallest unit or this behaviour if none. Needs more Discussion |
|
I think we can agree that the truncated form is also valuable. The idea would be to consider an API (like an options bag as an argument) to invoke a less-truncated mode, e.g., if you want the width of a bunch of strings to be the same. We can discuss this more, but since this is additive and small, it doesn't block the polyfill from being shipped. |
|
One proposal would be to add an options argument to However, it's well known by now that I don't like proliferation of options. 😄 So, another proposal would be to always output the seconds, but continue omitting trailing zeros (and the decimal point, if applicable) in the fractional part. (Omitting the seconds is the only thing that breaks sorting, I think?)
Can you elaborate? Is it for readability? If so, wouldn't it be better to use |
|
Instead of new options, why not simply offer the same rounding options ( This may address any readability concerns as well as provide rounding as well as truncation. And it'd allow fine-grained control over precision for interop with other systems that can't handle nanoseconds. |
|
BTW, I added the proposed solution above to #827. Feedback appreciated! |
|
FWIW, JSCalendar (the JSON counterpart to iCalendar/RFC5545) has this to say re: truncation:
|
|
Per 2020-08-28 meeting, we removed
|
|
Also, adding some use cases removed from #827:
|
|
Meeting, Sept. 18: We agree that we want to be able to set the output precision in any case, so we do want this, but we need a proposal on the table for how the option actually works. |
|
Did someone volunteer to build this proposal? There are only a handful of remaining open issues affecting API shape, so does it make sense to assign owners to each one so they don't get lost and do get prompt attention? |
|
that one is on me
…On Fri, 18 Sep 2020 at 23:05, Justin Grant ***@***.***> wrote:
Did someone volunteer to build this proposal? There are only a handful of
remaining open issues affecting API shape, so does it make sense to assign
owners to each one so they don't get lost and do get prompt attention?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#329 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADM5L27ZK43HIFNEAQYEWLSGPKSDANCNFSM4KLRV6DQ>
.
|
|
This proposal is now described in #703 and has only one open question left at the time of writing. The precision part can be implemented separately from the rest, so maybe it's a good idea to keep this issue open and do the precision part first. |
|
Here's what's ready to be implemented on this issue, the parts of #703 that don't depend on ZonedDateTime:
|
ptomato
added
documentation
This will be reused in Temporal.Instant.prototype.toString when we add precision options. See: #329
On DateTime.toString(), Time.toString(), and Instant.toString(), we add an options bag with the options `fractionalSecondDigits`, `smallestUnit`, and `roundingMode`. `smallestUnit` and `fractionalSecondDigits` control which units are output, and `roundingMode` is a rarely-needed option that allows other rounding behaviour than truncation. The default behaviour is changed as well. Previously seconds would not be output if the seconds and lower components would be 0, and the precision after the decimal point would be 0, 3, 6, or 9. After this change, seconds are always output, and all trailing zeroes after the decimal point are dropped. This change requires a lot of adjustments to expected test output. Closes: #329
In toString() we are going to have a different default rounding mode than in round() and difference(), so don't hardcode the default in the abstract operation. See: #329
This will be reused in Temporal.DateTime.prototype.toString when we add precision options. See: #329
This will be reused in Temporal.Instant.prototype.toString when we add precision options. See: #329
On DateTime.toString(), Time.toString(), and Instant.toString(), we add an options bag with the options `fractionalSecondDigits`, `smallestUnit`, and `roundingMode`. `smallestUnit` and `fractionalSecondDigits` control which units are output, and `roundingMode` is a rarely-needed option that allows other rounding behaviour than truncation. The default behaviour is changed as well. Previously seconds would not be output if the seconds and lower components would be 0, and the precision after the decimal point would be 0, 3, 6, or 9. After this change, seconds are always output, and all trailing zeroes after the decimal point are dropped. This change requires a lot of adjustments to expected test output. Closes: #329
In toString() we are going to have a different default rounding mode than in round() and difference(), so don't hardcode the default in the abstract operation. See: #329
This will be reused in Temporal.DateTime.prototype.toString when we add precision options. See: #329
This will be reused in Temporal.Instant.prototype.toString when we add precision options. See: #329
On DateTime.toString(), Time.toString(), and Instant.toString(), we add an options bag with the options `fractionalSecondDigits`, `smallestUnit`, and `roundingMode`. `smallestUnit` and `fractionalSecondDigits` control which units are output, and `roundingMode` is a rarely-needed option that allows other rounding behaviour than truncation. The default behaviour is changed as well. Previously seconds would not be output if the seconds and lower components would be 0, and the precision after the decimal point would be 0, 3, 6, or 9. After this change, seconds are always output, and all trailing zeroes after the decimal point are dropped. This change requires a lot of adjustments to expected test output. Closes: #329
In toString() we are going to have a different default rounding mode than in round() and difference(), so don't hardcode the default in the abstract operation. See: #329
This will be reused in Temporal.DateTime.prototype.toString when we add precision options. See: #329
This will be reused in Temporal.Instant.prototype.toString when we add precision options. See: #329
On DateTime.toString(), Time.toString(), and Instant.toString(), we add an options bag with the options `fractionalSecondDigits`, `smallestUnit`, and `roundingMode`. `smallestUnit` and `fractionalSecondDigits` control which units are output, and `roundingMode` is a rarely-needed option that allows other rounding behaviour than truncation. The default behaviour is changed as well. Previously seconds would not be output if the seconds and lower components would be 0, and the precision after the decimal point would be 0, 3, 6, or 9. After this change, seconds are always output, and all trailing zeroes after the decimal point are dropped. This change requires a lot of adjustments to expected test output. Closes: #329
In toString() we are going to have a different default rounding mode than in round() and difference(), so don't hardcode the default in the abstract operation. See: #329
This will be reused in Temporal.DateTime.prototype.toString when we add precision options. See: #329
This will be reused in Temporal.Instant.prototype.toString when we add precision options. See: #329
On DateTime.toString(), Time.toString(), and Instant.toString(), we add an options bag with the options `fractionalSecondDigits`, `smallestUnit`, and `roundingMode`. `smallestUnit` and `fractionalSecondDigits` control which units are output, and `roundingMode` is a rarely-needed option that allows other rounding behaviour than truncation. The default behaviour is changed as well. Previously seconds would not be output if the seconds and lower components would be 0, and the precision after the decimal point would be 0, 3, 6, or 9. After this change, seconds are always output, and all trailing zeroes after the decimal point are dropped. This change requires a lot of adjustments to expected test output. Closes: #329
In toString() we are going to have a different default rounding mode than in round() and difference(), so don't hardcode the default in the abstract operation. See: #329
This will be reused in Temporal.DateTime.prototype.toString when we add precision options. See: #329
This will be reused in Temporal.Instant.prototype.toString when we add precision options. See: #329
On DateTime.toString(), Time.toString(), and Instant.toString(), we add an options bag with the options `fractionalSecondDigits`, `smallestUnit`, and `roundingMode`. `smallestUnit` and `fractionalSecondDigits` control which units are output, and `roundingMode` is a rarely-needed option that allows other rounding behaviour than truncation. The default behaviour is changed as well. Previously seconds would not be output if the seconds and lower components would be 0, and the precision after the decimal point would be 0, 3, 6, or 9. After this change, seconds are always output, and all trailing zeroes after the decimal point are dropped. This change requires a lot of adjustments to expected test output. Closes: #329
I overlooked Duration in #329. This adds the same options except that the values for smallestUnit are preferred to be plural, and 'minutes' is not allowed.
I overlooked Duration in #329. This adds the same options except that the values for smallestUnit are preferred to be plural, and 'minutes' is not allowed.
Date.prototype.toISOStringalways returns a serialization at full resolution including all time elements, butTemporal.DateTime.prototype.toStringandTemporal.Time.prototype.toStringtruncate trailing zeroes. This inconsistent output can disrupt the readability of list output, and even break sorting:Is there a benefit that justifies this behavior?
The text was updated successfully, but these errors were encountered: