Maybe this needs to be shorter, like Dur2, to avoid failing checks? I am unfamiliar with the error here.

Maybe this needs to be shorter, like Dur2, to avoid failing checks? I am unfamiliar with the error here.

"Overfull \hbox" is latex telling us there's a long-and-unbreakable word at the end of a line overflowing ~10pts (in these cases) into the margin, and that wrapping it to the next line would leave too much whitespace on the current line. In other words, it can't find a way to flow this text that doesn't look terrible within the constraints it has been given.

The fix is for a human to look at the generated output to see what the problem word is, and either introduce a discretionary hyphen with \- ("If you have to break this word break it here and add a hyphen"), or a plain discretionary linebreak with \brk{} (ditto, but with no hyphen - generally used for code), or by rephrasing the prose so the problem word doesn't encroach into the right margin.

See StephanTLavavej#1.

The "where ..." phrase seems to imply we're talking about a fresh Duration here, but there is another Duration in scope that makes that a stretch. @jwakely , did you implement this?

We have not implemented this yet.

Thanks for bringing this to my attention @jensmaurer.

This does look like a defect to me, and the fix looks correct to me. Somehow when translating the original documentation to the proposed wording, I introduced this bug.

Here is the original documentation: https://howardhinnant.github.io/date/tz.html#clock_cast Search for:

"template
auto
operator()(const utc_time& t) const
-> decltype(DestClock::from_utc(t));"

Remarks: This function does not participate in overload resolution unless DestClock::from_utc(t) is well formed. If DestClock::from_utc(t) does not return time_point<DestClock, _some duration_> the program is ill-formed.

I.e. it was some duration that was intended instead of Duration, and the proposed fix subs in Duration2 where some duration was in the original documentation.

@tkoeppe, @jwakely: Any opposition to fixing this editorially, given that @HowardHinnant said the pull request manifests the intended behavior?

Editorial meeting 2021-04-30: Given the opinions of the stakeholders, this is considered editorial.

@jwakely, @CaseyCarter: Please take note that we're making this change editorially.

Sorry for the late comment, but couldn't this be further simplified? What is a "valid" duration? [time.duration.general] already says that invalid specializations are ill-formed, and time_point requires a duration. So isn't the requirement here just that it returns a time point with the right clock?

Specifically, I think that both instances of "where Duration2 is a valid chrono::duration specialization" could be changed to "for some Duration2" with no change in meaning.

No opinion either way here.

I appreciate the concerns, and I sympathize with them, but given the rather invasive nature (from a "squint the wrong way" standpoint) of this pull request, I'd suggest to merge it as-is and have a separate issue to look for "valid specializations" in all of [time]. (I suspect there are more of these).

That works for me

The only other cases are [time.clock.cast.sys] and [time.clock.cast.utc]. This change seems consistent with the language there. I think we could remove "valid" there without changing the meaning.

@jwakely Please let's follow up on the simplification suggestions. I created #4613 to track that.