C++ Logo

std-proposals

Advanced search

Re: C++20 chrono library can't use max date?

From: Andrey Semashev <andrey.semashev_at_[hidden]>
Date: Sat, 21 Dec 2019 16:42:44 +0300
On 2019-12-21 11:54, Akira Takahashi via Std-Proposals wrote:
> 2019年12月21日(土) 17:06 Bo Persson via Std-Proposals
> <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>>:
>
>
> 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...).
>
>
> I think we should have consistent valid range.
> Normally, min() and max() function means valid range. However,
> system_clock::time_point::max() is invalid.
> If you right, why valid range is not 500 years? What's the mean
> time_point::max(), min()?
>
> I need how to know valid range.
>

The min/max functions give you the valid range. Note that it will be
different, depending on the representation type and resolution. If you
want wider range and not high resolution, just define your time points
and durations appropriately. If you want both, use a representation type
that allows you that. And you can define your own clock type that will
provide the time points you require. This flexibility is one of key
design advantages of chrono.

Time points and durations, at least from the system and steady clocks,
are not intended to be used for representing calendar dates, especially
not in the far past or future. One of their main use cases is relatively
short term timed operations (e.g. various timeouts, operation intervals
and scheduling, etc.), meaning that magnitute orders of sub-seconds to
seconds are much more prevalent than hours, days or even years. These
clocks and associated time points and durations are designed to be
efficient for that use case. Choosing e.g. a larger representation type
to increase the range would add unneeded performance overhead.

Received on 2019-12-21 07:45:15