Predefined durations in std::chrono

[VinceRev]

Hello.

Currently, the standard library defines the following types in std::chrono

std::chrono::nanoseconds / duration type with Period std::nano
std::chrono::microseconds / duration type with Period std::micro
std::chrono::milliseconds / duration type with Period std::milli
std::chrono::seconds / duration type with Period std::ratio<1>
std::chrono::minutes / duration type with Period std::ratio<60>
std::chrono::hours / duration type with Period std::ratio<3600>

I think that this list misses two common and well defined durations : days and years :

std::chrono::days / duration type with Period std::ratio<86400> (the unit of time defined in 1967 as 86400 SI seconds an written d)
std::chrono::years / duration type with Period std::ratio<31557600> (the julian year which consists of 365.25 days of 86400 seconds each)

Is there any reason not to integrate these durations in the standard ?

Furthermore I think it could be usefull to be able to specify the Rep template parameter of these durations :
For example std::chrono::hours would be redefined as : template<class Rep> std::chrono::hours which is equivalent to std::chrono::duration<Rep, std::ratio<3600> >

What is your point of view on that ?

Thank you very much.
Vincent Reverdy

[Marc]

On Wednesday, November 14, 2012 6:06:37 AM UTC+1, VinceRev wrote:

std::chrono::days / duration type with Period std::ratio<86400> (the unit of time defined in 1967 as 86400 SI seconds an written d)

Why not.
 

std::chrono::years / duration type with Period std::ratio<31557600> (the julian year which consists of 365.25 days of 86400 seconds each)

Why take the Julian year? The length of a year may not be defined well enough for the standard to add it.

[Anthony Williams]

On 14/11/12 05:06, VinceRev wrote:
> Currently, the standard library defines the following types in std::chrono
>
> std::chrono::nanoseconds / duration type with Period std::nano
> std::chrono::microseconds / duration type with Period std::micro
> std::chrono::milliseconds / duration type with Period std::milli
> std::chrono::seconds / duration type with Period std::ratio<1>
> std::chrono::minutes / duration type with Period std::ratio<60>
> std::chrono::hours / duration type with Period std::ratio<3600>
>
> I think that this list misses two common and well defined durations :
> days and years :

Yes. That was deliberate. These durations are primarily intended for use
with functions that have timeouts, such as std::future<T>::wait_for or
std::this_thread::sleep_for. Such long timeouts would definitely be an
unusual occurrence. Also, longer time periods are often ill-defined, and
have different meanings in different contexts. Even "day" can be subject
to such inconsistencies.

Finally, we deliberately shied away from anything that related to
calendar systems, in anticipation that a future C++ standard would
provide a wider date-time framework. A duration of "3 days" could thus
be specified with reference to that framework if necessary.

> Furthermore I think it could be usefull to be able to specify the Rep
> template parameter of these durations :
> For example std::chrono::hours would be redefined as : template<class
> Rep> std::chrono::hours which is equivalent to
> std::chrono::duration<Rep, std::ratio<3600> >
>
> What is your point of view on that ?

std::duration<> is the template for this; there is no need for
additional templates with pre-specified ratios.

Anthony
--
Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/
just::thread C++11 thread library http://www.stdthread.co.uk
Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk
15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

[Howard Hinnant]

On Nov 14, 2012, at 12:06 AM, VinceRev <vinc...@gmail.com> wrote:

> std::chrono::years / duration type with Period std::ratio<31557600> (the julian year which consists of 365.25 days of 86400 seconds each)

<trivia>

The mean civil (Gregorian) calendar year is actually 31,556,952 seconds. The mean civil calendar month is also an integral number of seconds. :-)

</trivia>

Howard

[DeadMG]

Considering the fun you can have with leap years, leap days, and all sorts, I agree that this should be deferred until a proper calendar framework is Standardised.

[Vincent R]

Just as a remark, in my mind, these durations would not be related to any calendar : the day of 86400 seconds is a kind a standardized one (see http://www.bipm.org/en/si/si_brochure/chapter4/table6.html) to measure duration. And for the year, the julian year is the one used in several units like the light-year (and the light year does not depend on any calendar of course).

2012/11/14 DeadMG <wolfei...@gmail.com>

Considering the fun you can have with leap years, leap days, and all sorts, I agree that this should be deferred until a proper calendar framework is Standardised.

--
 
 
 

--
Vincent Reverdy
Doctorant au Laboratoire Univers et Théories
Groupe Cosmologie et Gravitation Relativiste
Observatoire de Paris-Meudon

[Daniel Krügler]

2012/11/14 Vincent R <vinc...@gmail.com>

Just as a remark, in my mind, these durations would not be related to any calendar : the day of 86400 seconds is a kind a standardized one (see http://www.bipm.org/en/si/si_brochure/chapter4/table6.html) to measure duration. And for the year, the julian year is the one used in several units like the light-year (and the light year does not depend on any calendar of course).

Presumably there can be found agreement on "day", but I consider "year" as one unit where agreement on the
definition is hard to find. Many people (not involved with astrophysics) find the Julian year not appropriate for daily use, further, there are so many other options to define a constant and context-free definition of a year unit (especially but not restricted to astrophysics), that I don't see why the Julian year is a clearer winner for a standard that is generally unaware of special use-cases.

It is really not a burden to define your own unit of any kind of a year, so I don't find yet good reasons to add "year" to chrono with potential misleading interpretation.

Once a calendar will be considered for the library, it is very natural to add the corresponding year definition, too, so this is why the argument in regard to calendars is often brought forward.

- Daniel

[ri...@longbowgames.com]

On Wednesday, November 14, 2012 1:31:39 PM UTC-5, Daniel Krügler wrote:

Presumably there can be found agreement on "day"

If only it were so. Sometimes a day is 25 or 23 hours (thanks to leap hours), and sometimes it's 24 hours and 1 second (thanks to leap seconds, which aren't even predictable, and are known to cause real problems).

What this means is that duration(2012-06-30, 2012-07-01) = 1 day = 86401 seconds. That assumes you're using civil time, like UTC or EST. If you're using GPS or TAI time, then a day is always 86400 seconds. Unfortunately, system clocks usually aren't based on GPS or TAI time. So while you might want to use GPS time when writing navigation systems, you'll want to use UTC when writing web browsers.

It's a sticky situation that needs a comprehensive solution. If we implement a half-baked solution, we might need to redefine what a day means once the comprehensive solution comes along, and nobody wants that.