------=_Part_443_19293076.1352869597626
Content-Type: text/plain; charset=ISO-8859-1

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

--




------=_Part_443_19293076.1352869597626
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello.<br><br>Currently, the standard library defines the following types i=
n std::chrono<br><br>std::chrono::nanoseconds / duration type with Period s=
td::nano<br>std::chrono::microseconds / duration type with Period std::micr=
o<br>std::chrono::milliseconds / duration type with Period std::milli<br>st=
d::chrono::seconds / duration type with Period std::ratio&lt;1&gt;<br>std::=
chrono::minutes / duration type with Period std::ratio&lt;60&gt;<br>std::ch=
rono::hours / duration type with Period std::ratio&lt;3600&gt;<br><br>I thi=
nk that this list misses two common and well defined durations : days and y=
ears :<br><br>std::chrono::days / duration type with Period std::ratio&lt;8=
6400&gt; (the unit of time defined in 1967 as 86400 SI seconds an written d=
)<br>std::chrono::years / duration type with Period std::ratio&lt;31557600&=
gt; (the julian year which consists of 365.25 days of 86400 seconds each)<b=
r><br>Is there any reason not to integrate these durations in the standard =
?<br><br>Furthermore I think it could be usefull to be able to specify the =
Rep template parameter of these durations :<br>For example std::chrono::hou=
rs would be redefined as : template&lt;class Rep&gt; std::chrono::hours whi=
ch is equivalent to std::chrono::duration&lt;Rep, std::ratio&lt;3600&gt; &g=
t;<br><br>What is your point of view on that ?<br><br>Thank you very much.<=
br>Vincent Reverdy<br>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_443_19293076.1352869597626--

.

------=_Part_499_22874518.1352878942059
Content-Type: text/plain; charset=ISO-8859-1

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.

--




------=_Part_499_22874518.1352878942059
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wednesday, November 14, 2012 6:06:37 AM UTC+1, VinceRev wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;">std::chrono::days / duration type with P=
eriod std::ratio&lt;86400&gt; (the unit of time defined in 1967 as 86400 SI=
 seconds an written d)<br></blockquote><div><br>Why not.<br>&nbsp;</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-l=
eft: 1px solid rgb(204, 204, 204); padding-left: 1ex;">std::chrono::years /=
 duration type with Period std::ratio&lt;31557600&gt; (the julian year whic=
h consists of 365.25 days of 86400 seconds each)<br></blockquote><div><br>W=
hy take the Julian year? The length of a year may not be defined well enoug=
h for the standard to add it.<br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_499_22874518.1352878942059--

.

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

--




.

On Nov 14, 2012, at 12:06 AM, VinceRev <vince.rev@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

--




.

------=_Part_546_4141080.1352912579955
Content-Type: text/plain; charset=ISO-8859-1

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.

--




------=_Part_546_4141080.1352912579955
Content-Type: text/html; charset=ISO-8859-1

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.

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_546_4141080.1352912579955--

.

--f46d0447966de413a304ce77b57a
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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 <wolfeinstein@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.
>
> --
>
>
>
>



--=20
Vincent Reverdy*
**Doctorant au Laboratoire Univers et Th=E9ories**
Groupe Cosmologie et Gravitation Relativiste
Observatoire de Paris-Meudon
***

--=20




--f46d0447966de413a304ce77b57a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Just as a remark, in my mind, these durations would not be related to any c=
alendar : the day of 86400 seconds is a kind a standardized one (see <a hre=
f=3D"http://www.bipm.org/en/si/si_brochure/chapter4/table6.html">http://www=
..bipm.org/en/si/si_brochure/chapter4/table6.html</a>) 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).=
<br>
<br><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2012/=
11/14 DeadMG <span dir=3D"ltr">&lt;<a href=3D"mailto:wolfeinstein@gmail.com=
" target=3D"_blank">wolfeinstein@gmail.com</a>&gt;</span><br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">
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.

<span class=3D"HOEnZb"><font color=3D"#888888"><p></p>

-- <br>
=A0<br>
=A0<br>
=A0<br>
</font></span></blockquote></div><br><br clear=3D"all"><br>-- <br>Vincent R=
everdy<em><br></em><i>Doctorant au Laboratoire Univers et Th=E9ories</i><em=
><br>Groupe Cosmologie et Gravitation Relativiste<br>Observatoire de Paris-=
Meudon<br>
</em><span><em></em></span><br>
</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--f46d0447966de413a304ce77b57a--

.

--bcaec54eecc6b1b30e04ce78be35
Content-Type: text/plain; charset=ISO-8859-1

2012/11/14 Vincent R <vince.rev@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

--




--bcaec54eecc6b1b30e04ce78be35
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">2012/11/14 Vincent R <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:vince.rev@gmail.com" target=3D"_blank">vince.rev@gmail.com</a>=
&gt;</span><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">
Just as a remark, in my mind, these durations would not be related to any c=
alendar : the day of 86400 seconds is a kind a standardized one (see <a hre=
f=3D"http://www.bipm.org/en/si/si_brochure/chapter4/table6.html" target=3D"=
_blank">http://www.bipm.org/en/si/si_brochure/chapter4/table6.html</a>) to =
measure duration. And for the year, the julian year is the one used in seve=
ral units like the light-year (and the light year does not depend on any ca=
lendar of course).<br>

<br></blockquote><div><br>Presumably there can be found agreement on &quot;=
day&quot;, but I consider &quot;year&quot; as one unit where agreement on t=
he<br>definition is hard to find. Many people (not involved with astrophysi=
cs) 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&#39;=
t see why the Julian year is a clearer winner for a standard that is genera=
lly unaware of special use-cases.<br>
<br>It is really not a burden to define your own unit of any kind of a year=
, so I don&#39;t find yet good reasons to add &quot;year&quot; to chrono wi=
th potential misleading interpretation.<br><br>Once a calendar will be cons=
idered for the library, it is very natural to add the corresponding year de=
finition, too, so this is why the argument in regard to calendars is often =
brought forward.<br>
<br>- Daniel<br><br></div><br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--bcaec54eecc6b1b30e04ce78be35--

.

------=_Part_614_17631930.1353383451632
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wednesday, November 14, 2012 1:31:39 PM UTC-5, Daniel Kr=FCgler 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=20
hours), and sometimes it's 24 hours and 1 second (thanks to leap seconds,=
=20
which aren't even predictable, and are known to cause real problems<http://=
www.wired.com/wiredenterprise/2012/07/leap-second-bug-wreaks-havoc-with-jav=
a-linux/>
).

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

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

--=20




------=_Part_614_17631930.1353383451632
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wednesday, November 14, 2012 1:31:39 PM UTC-5, Daniel Kr=FCgler wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div class=3D"gmail_quote"><=
div>Presumably there can be found agreement on "day"<br></div></div></block=
quote><div><br>If only it were so. Sometimes a day is 25 or 23 hours (thank=
s 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 <a href=3D"http://=
www.wired.com/wiredenterprise/2012/07/leap-second-bug-wreaks-havoc-with-jav=
a-linux/">cause real problems</a>).<br><br>What this means is that duration=
(2012-06-30, 2012-07-01) =3D 1 day =3D 86401 seconds. That assumes you're u=
sing civil time, like UTC or EST. If you're using GPS or TAI time, then a d=
ay is always 86400 seconds. Unfortunately, system clocks usually aren't bas=
ed 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.<br><=
br>It's a sticky situation that needs a comprehensive solution. If we imple=
ment a half-baked solution, we might need to redefine what a day means once=
 the comprehensive solution comes along, and nobody wants that.<br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_614_17631930.1353383451632--

.