On 2019-12-21 at 04:38, Akira Takahashi via Std-Proposals wrote:
>
>
> 2019年12月21日(土) 5:33 Thiago Macieira via Std-Proposals
> <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>>:
>
> On Friday, 20 December 2019 09:22:15 PST Akira Takahashi via
> Std-Proposals
> wrote:
> > `std::chrono::year` class has 16-bits signed integer for year
> > value. [-32767, 32767]
> >
> > However, `system_clock::time_point::max()` of libc++ implementation
> > has 294247 years (microseconds based). So, C++20 chrono library
> can't use
> > max date.
> > Is this defect or correct?
>
> It's correct.
>
> And libstdc++ is even shorter, with just 294.2 years (nanosecond based).
>
>
> Why correct the behavior?
> std::ctime() C function can shows 294247 years. But cout << maxdate;
> shows overflowed years. Because the follow output stream function uses
> year_month_day class.
>
> basic_osteam& operator<<(basic_ostream&, const sys_time<Duration>&);
>
> Effects:
> auto const dp = floor<days>(tp);
> return os << format(os.getloc(), STATICALLY-WIDEN<charT>("{} {}"),
> year_month_day{dp}, hh_mm_ss{tp-dp});
>
> What is the rationale for inferior behavior to the C API?
>
>

What is the use case for a wider range? The current civil calendar has
"only" been in use for about 500 years.

So what does it mean to have a date 100.000 years into the future? It
will surely be incorrect anyway becase of some political decisions made
before we get there (if we ever do...).


     Bo Persson