<chrono>
formatting: fix UB, various cleanups
#1848
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.
_Has_ok
._Last_day_table
._Month
could be bogus, so we need to mask the value._Chrono_formatter
whether to_Allow_precision
, teach its_Parse
to determine that by inspecting_Ty
. This avoids potential mistakes, and allows us to customize theformat_error
message. (We need separate cases for integral-duration
and non-duration
, due to the need to inspecttypename _Ty::rep
.)_Chrono_formatter
so we can provide a time zone abbreviation, instead of setting it later. This slightly reduces verbosity in theformatter
s below. (Eventually,_Chrono_formatter
could probably lock down its access control instead of having public data members, but I'm not changing that here.)if
-statements.hh_mm_ss
range check to follow the number line (most negative on the left).hh_mm_ss
format_error
: exact-24h
and24h
are errors._Time_zone_abbreviation{};
. This isn't necessary, but makes it clear that we haven't forgotten about it.constexpr
offsets when formattingtai_time
andgps_time
.<chrono>
and I didn't want to bother with moving them).