https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126387

            Bug ID: 126387
           Summary: formatting of file_time time point wraps and can't
                    format whole representable time range
           Product: gcc
           Version: 17.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hanicka at hanicka dot net
  Target Milestone: ---

I have noticed that formatting file_time<nanoseconds> wraps unexpectedly:

This is the highest possible value I can print without wrapping:
```c+++
auto highest =
std::chrono::file_time<std::chrono::nanoseconds>{std::chrono::seconds{2785708036}
+ std::chrono::nanoseconds{854775807}};
std::cout << highest;
```
will print: "2262-04-11 23:47:16.854775807"

if I add one nanosecond:
```c++
auto wrapping =
std::chrono::file_time<std::chrono::nanoseconds>{std::chrono::seconds{2785708036}
+ std::chrono::nanoseconds{854775808}};
std::cout << wrapping;
```

will print: "1677-09-21 00:12:43.854775808"

notice the nanosecond part same, but dates and hh:mm:ss are different
completely.

your file_clock should represent range between years 1901-2446

https://github.com/gcc-mirror/gcc/blob/380bd5c411037ee59c1db96b6d0f882e06d91d5d/libstdc%2B%2B-v3/include/bits/chrono.h#L1491-L1494

When I found about the range, I was curious if someone Jonathan who picked the
range (or at least wrote the comment) is a trekkie, so I tried to find exact
date when the range ends, and found this bug.

In following compiler-explorer link I print multiple values:
min/zero/max/highest not wrapping/after wrap

https://compiler-explorer.com/z/zoevfzEMa

I would expect:

std::chrono::file_time<std::chrono::nanoseconds>{std::chrono::nanoseconds{std::numeric_limits<long
int>::min()}} should format to "1901-something"

std::chrono::file_time<std::chrono::nanoseconds>{std::chrono::nanoseconds{std::numeric_limits<long
int>::max()}} should format to "2446-something"

I guess similar problem will be (less pronounced) in formatting of other offset
timepoints to sys_clock.

Reply via email to