https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114260
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Yup, I understand why that's the output. I just thought it seemed off that
something rounded to days didn't land at 00:00:00 and convinced myself that it
should be "corrected". But of course utc_time<days> is not a year_month_day,
it's an exact time point, and it happens to not line up with 00:00:00 for the
reason you gave:
(In reply to Howard Hinnant from comment #2)
> Consequently, 2024-03-05 00:00:00 in utc_time is *not* a multiple of 86400s,
> but rather 27s greater than a multiple of 86400s. And all
> round<days>(udays) does is round the .time_since_epoch() to the nearest
> multiple of 86400s. Which in utc_time is 27s earlier, or 2024-03-04
> 23:59:33.
So not a bug then. Thanks for talking me out of introducing a bug here!
