According to N2661, the paper that added <chrono>
:
This paper does not offer calendrical services except for a minimal
mapping to and from C’stime_t
.As this paper does not propose a date/time library, nor specify epochs, it also does not address leap seconds. However, a date/time
library will find this to be an excellent foundation on which to
build.This paper does not propose a general purpose physical quantities
library.This paper proposes a solid foundation that, in the future, could provide a compatible starting point for a general physical units
library. While such a future library might take any of several forms,
the present proposal stops well short of actually being a physical
units library. This proposal is time-specific, and continues to be
motivated by the time-related needs of the threading library.The major goal of this proposal is to satisfy the needs of the
standard library threading API in a manner which is easy to use, safe
to use, efficient, and flexible enough to not be obsolete 10 or even
100 years from now. Every feature contained in this proposal is here
for a specific reason with practical use cases as motivation. Things
that fell into the category of “cool”, or “that sounds like it might
be useful”, or “very useful but not needed by this interface” have not
been included. Such items might appear in other proposals, and
possibly target a TR.
Note that the major goal of <chrono>
is “to satisfy the needs of the standard library threading API”, which does not require calendar services.