Convert DateTime::with_nanosecond
to return Result
#1520
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As I see it
DateTime::with_nanosecond
is one of the few methods onDateTime
that does not need to return an error from theTimeZone
trait and does not need to return aMappedLocalTime
.We assume in some places, like the platform code of
Local
, that time zone transitions happen on second boundaries. That seems entirely reasonable to me and fits with reality. There is also some similarity to how we assume offsets to be a round number of seconds from UTC.In the IANA time zone database there are some time zone offsets from the 19th century that have an offset with fractional seconds. Those are based on the longitude of a city or mean of the country. The fractional part is included with a comment, and the shipped data uses round seconds. Necessarily if anyone takes those fractional offsets serious, they would need a transitions at a fractional second at some point when the country aligns from local mean time to round offsets from UTC.
If we assume there are no subsecond transitions
DateTime::with_nanosecond
can just assume the entire second has the same offset from UTC.