Useful time utilities. C++11.
Distributed under the Boost Software License, Version 1.0.
Boost.org chrono module
Home Page: http://boost.org/libs/chrono
Useful time utilities. C++11.
Distributed under the Boost Software License, Version 1.0.
Severity Code Description Project File Line Suppression State
Error LNK1104
cannot open file 'libboost_chrono-vc142-mt-sgd-x64-1_77.lib'
Boost_ASIO_HTTP_Async_Client C:\Users...\Console_boost_asio_http_async_client\LINK 1
The file 'libboost_chrono-vc142-mt-sgd-x64-1_77.lib' is really missing, but similar file exist:
C:\Libs\boost_1_77_0\bin.v2\libs\chrono\build\msvc-14.2\debug\link-static\threading-multi\libboost_chrono-vc142-mt-gd-x64-1_77.lib
Code:
boost::chrono::system_clock::time_point before = boost::chrono::system_clock::now(); //do some work boost::chrono::system_clock::time_point now = boost::chrono::system_clock::now(); boost::chrono::nanoseconds t = boost::chrono::duration_cast<boost::chrono::nanoseconds>(now - before); std::cout << t.count() << "\n";
In this routine:
inline int32_t days_from_1970(int32_t year)
{
static const int days_from_0_to_1970 = days_from_0(1970);
return days_from_0(year) - days_from_0_to_1970;
}
Shouldn't type "int" above (for variable 'days_from_0_to_1970') actually be "int32_t"?
The documentation says it should have been set to 2 since Boost 1.55. But as of writing this issue the default value is still set to 1.
In case when no year or day of month is specified in the time format, stream extraction of a time_point
will yield incorrect results. The reason for this is that struct std::tm
is initialised in various places to all zeroes using memset
, which is not correct, because in this struct day of month is counted from 1, not 0, and years are counted from 1900, not 1970. Therefore, if the fields are passed unmodified to timegm
(which is the case when the parsed timestamp has no year or day in its format), the result will be off by the relevant differences.
For example, if "01" is parsed with time format "%S", the expected result would be 1970-01-01T00:00:01, but instead it's 1899-12-31T00:00:01.
The binary subtraction operation tp - d
is implemented as tp + (-d)
.
Because the unary minus operator is used, the result is wrong if the underlying representation type is unsigned.
For instance :
#include <cassert>
#include <chrono>
#include <iostream>
#include <boost/chrono.hpp>
// namespace chrono = std::chrono;
// using std::micro;
namespace chrono = boost::chrono;
using boost::micro;
int main() {
const auto tp = chrono::system_clock::time_point(chrono::milliseconds(0));
chrono::duration<uint32_t, micro> delay(1);
std::cout << (tp - delay).time_since_epoch().count() << std::endl;
assert((tp - delay).time_since_epoch().count() == -1000);
return 0;
}
Running this program produces the following output:
4294967295000
a: /tmp/a.cpp:16: int main(): Assertion `(tp - delay).time_since_epoch().count() == -1000' failed.
Note that the std::chrono from gcc does not exhibit this defect.
I'm seeing this while building Boost.Thread in cygwin (32-bit). I added code to dump the values of t0 through t3 in the file sync/mutual_exclusion/locks/shared_lock/cons/try_to_lock_pass.cpp
. When it fails, which seems to be about 75% of the time, t0 is zero (ran this from thread/test):
$ ../../../b2.exe toolset=gcc variant=release warnings-as-errors=on warnings=all --abbreviate-paths define=_POSIX_C_SOURCE=200112L threadapi=pthread address-model=32 cxxstd=11
-q cxxflags=-Wno-unknown-pragmas cxxflags=-Wno-unused-variable cxxflags=-Wno-unused-but-set-variable shared_lock__cons__try_to_lock_p
Performing configuration checks
- default address-model : 32-bit (cached)
- default architecture : x86 (cached)
- symlinks supported : yes (cached)
- lockfree boost::atomic_flag : yes (cached)
...patience...
...patience...
...found 3243 targets...
...updating 2 targets...
testing.capture-output ../../../bin.v2/libs/thread/test/shared_lock__cons__try_to_lock_p.test/gcc-7.3.0/rls/cxstd-11-iso/thrdp-pthrd/thrd-mlt/vsblt-hdn/shared_lock__cons__try_t
o_lock_p.run
====== BEGIN OUTPUT ======
t0=0 nanoseconds since boot
t1=203061006792900 nanoseconds since boot
t2=203060757198500 nanoseconds since boot
t3=203061006765200 nanoseconds since boot
sleep_time=249566700 nanoseconds
d_ms=203060757 milliseconds
d_ns=203060757226200 nanoseconds
sync/mutual_exclusion/locks/shared_lock/cons/try_to_lock_pass.cpp(120): test '(d_ms).count() < (max_diff).count()' ('203060757' < '250') failed in function 'int main()'
sync/mutual_exclusion/locks/shared_lock/cons/try_to_lock_pass.cpp(121): test '(d_ns).count() < (ns(max_diff)).count()' ('203060757226200' < '250000000') failed in function 'int
main()'
2 errors detected.
EXIT STATUS: 1
====== END OUTPUT ======
If I call boost::chrono::high_resolution_clock::now() from the main thread before it gets called from the second thread, everything is fine.
The following small code is a minimal excerpt from the testsuite which exhibits the problem. AFAICS there is no way for users to avoid these warnings.
Compile the program f.e. using cl /c /EHsc /W4 test.cpp
to generate the warnings as shown in PR#24
#include <boost/chrono.hpp>
#include <sstream>
using Clock = boost::chrono::high_resolution_clock;
using Duration = boost::chrono::hours;
using TimePoint = boost::chrono::time_point<Clock, Duration>;
void test1(const char * s) {
std::istringstream in(s);
Duration d;
in >> d;
}
void test2(const char * s) {
std::istringstream in(s + boost::chrono::clock_string<Clock, char>::since());
TimePoint tp;
in >> tp;
}
int main() {
test1("5000 hours");
test2("5000 hours");
return 0;
}
I'm can't compile my code when boost/chrono/chrono_io.hpp is included. I tried compilers:
g++ (Ubuntu 12.2.0-3ubuntu1) 12.2.0
and
AMD clang version 14.0.6 (CLANG: AOCC_4.0.0-Build#434 2022_10_28) (based on LLVM Mirror.Version.14.0.6)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /opt/AMD/aocc-compiler-4.0.0/bin
Error is:
In file included from boost_1_80_0/aocc/include/boost/chrono/chrono_io.hpp:29:
In file included from boost_1_80_0/aocc/include/boost/chrono/io_v1/chrono_io.hpp:26:
In file included from boost_1_80_0/aocc/include/boost/chrono/detail/scan_keyword.hpp:22:
boost_1_80_0/aocc/include/boost/move/unique_ptr.hpp:133:12: error: expected class member or base class name
: D(), m_p()
^
boost_1_80_0/aocc/include/boost/move/unique_ptr.hpp:137:12: error: expected class member or base class name
: D(), m_p(p)
^
boost_1_80_0/aocc/include/boost/move/unique_ptr.hpp:141:14: error: expected class member or base class name
: D(d1), m_p(p)
^
boost_1_80_0/aocc/include/boost/move/unique_ptr.hpp:146:34: error: expected class member or base class name
: D(::boost::forward(d)), m_p(p)
^
Why is there no something like boost::chrono::*something*::timegm(std::tm *)
?
At the same time, chrono use timegm
in time_point_io.hpp
If there are no objective reasons for this, I would like to write it.
If I compile the following with g++
:
#include <boost/chrono/io/duration_io.hpp>
…I get compiler warnings:
In file included from ./boost/config/header_deprecated.hpp:18,
from ./boost/detail/scoped_enum_emulation.hpp:15,
from ./boost/chrono/io/duration_style.hpp:13,
from boost/chrono/io/duration_io.hpp:15:
./boost/detail/scoped_enum_emulation.hpp:17:1: note: ‘#pragma message: This header is deprecated. Use <boost/core/scoped_enum.hpp> instead.’
17 | BOOST_HEADER_DEPRECATED("<boost/core/scoped_enum.hpp>")
| ^~~~~~~~~~~~~~~~~~~~~~~
./boost/detail/no_exceptions_support.hpp:17:1: note: ‘#pragma message: This header is deprecated. Use <boost/core/no_exceptions_support.hpp> instead.’
17 | BOOST_HEADER_DEPRECATED("<boost/core/no_exceptions_support.hpp>")
| ^~~~~~~~~~~~~~~~~~~~~~~
(eg see https://godbolt.org/z/3qb6PeWdd )
This shows that Boost Chrono is using deprecated headers. From what I can see, the usages in the current commit are:
include/boost/chrono/io/duration_io.hpp:20
include/boost/chrono/io/duration_style.hpp:13
include/boost/chrono/io/time_point_io.hpp:32
include/boost/chrono/io/timezone.hpp:12
It looks like those deprecation warnings were put in place with this commit in November 2019.
I realise this isn't a catastrophic problem but it's probably to move off the deprecated headers and the warnings can inject quite a lot of noise into a build's output (and it isn't silenced by -isystem
).
Thank you very much for all work on this library.
https://github.com/boostorg/chrono/blob/develop/include/boost/chrono/io/time_point_io.hpp says it's covered by three licenses, and for two of them it says "See LICENSE.TXT for details." There is no such file in the repo.
As of boost 1.72, I'm getting "error: zero as null pointer constant" when using e.g. boost::chrono::milliseconds
. This can IMO be fixed by using nullptr
instead.
I've spotted the following places, but there might be more:
The documentation of boost::chrono::process_cpu_clock states that
(Boost.Chrono.Stopwatch is a clear example of this use)
But, Boost.Chrono.Stopwatch is nowhere to be found in the sources. Maybe it is old, maybe it is missing by accident.
The following simple program crashes (SIGSEGV) with Boost 1.71.0 when reaching in >> tp
:
#define BOOST_CHRONO_VERSION 2
#include <boost/chrono.hpp>
#include <boost/chrono/io/time_point_io.hpp>
#include <cassert> // assert
#include <sstream> // std::istringstream
#include <string> // std::string
int main() {
namespace bc = boost::chrono;
std::istringstream in("2019-09-16 13:16:31.539"); // missing offset
// bc::timezone_io_saver tzs(in, bc::timezone::local); // try this as well
bc::system_clock::time_point tp;
in >> tp; // crashes with default format
assert(in.eof());
assert(in.fail());
assert(!in.bad());
return 0;
}
The following diff prevents the crash and fulfills the assert
s:
--- boost/chrono/io/time_point_io.hpp.orig 2019-08-14 14:02:21.000000000 +0200
+++ boost/chrono/io/time_point_io.hpp 2019-09-16 20:13:47.435303802 +0200
@@ -1152,6 +1152,11 @@ namespace boost
}
It i(is);
It eof;
+ if (i == eof)
+ {
+ err |= std::ios_base::failbit;
+ goto exit;
+ }
c = *i;
if (++i == eof || c != ' ')
{
I built Boost without any specific customization, which is:
./bootstrap
./b2
Before 1.80, following codes can work properly (-std=c++98), but in 1.80, it must be compiled with -std=c++0x (or heigher) or with macro BOOST_CHRONO_HEADER_ONLY, otherwise, the timer can never expire. My query is -- is this a bug or right behavior by design?
void timer_handler(const boost::system::error_code& ec, const boost::shared_ptr<boost::asio::system_timer>&)
{
puts("receive a timeout event.");
}
void main()
{
boost::asio::io_context ctx[4];
for (int i = 0; i < 16; ++i)
{
BOOST_AUTO(timer, boost::make_shared<boost::asio::system_timer>(ctx[i % 4].get_executor()));
timer->expires_after(boost::chrono::milliseconds(50));
timer->async_wait(boost::bind(&timer_handler, boost::asio::placeholders::error, timer));
}
boost::thread_group tg;
for (int i = 0; i < 4; ++i)
tg.create_thread(boost::bind(&boost::asio::io_context::run, &ctx[i]));
tg.join_all();
}
We are in the process of making B2 build changes to all of the B2 build files
to support "modular" consumption of the Boost Libraries by users. See this list
post for some details: https://lists.boost.org/Archives/boost/2024/01/255704.php
The process requires making a variety of changes to make each Boost library
independent of the super-project structure. But the changes do not remove the
super-project structure or the comprehensive Boost release. The changes make
solely make it possible, optionally, for users, like package manages, to easily
consume libraries individually.
Generally the changes include:
Some examples of such changes:
We are asking how you would like us to handle the changes. We would prefer if
you allow the owners of the Boost.org GitHub project to make changes to B2
build files, as needed, to accomplish the changes. But understand
that you may want to manage the proposed changes yourself.
We previously sent emails to all known maintainers to fill out a form with their
preference. We are contacting you in this issue as we have not gotten a response
to that email. You can see the ongoing responses for that form and the responses
to these issues here https://github.com/users/grafikrobot/projects/1/views/6
We are now asking if you can reply directly to this issue to indicate your
preference of handling the changes. Please supply a response to this question
and close the issue (so that we can verify you are a maintainer).
How would you like the build changes to be processed?
Also please indicate any special instructions you want us to consider. Or other
information you want us to be aware of.
Thanks you, René
I discovered that Boost Chrono IO can occasionally add an incorrect time value (represented by a time _point object) to the stream. The problem occurs for the hour in which the local time shifts from standard to DST (summer time). Because the time is always displayed in GMT, it should not be affected by any changes in the local time zone, but in this case -- it is.
Example app:
#include <iostream>
#include <boost/chrono/chrono.hpp>
#include <boost/chrono/io/time_point_io.hpp>
using namespace boost::chrono;
static void print(const system_clock::time_point& tp)
{
std::cout << time_fmt(timezone::utc) <<
duration_cast<seconds>(tp.time_since_epoch()).count() << ": " << tp <<
std::endl;
}
int main(int /*argc*/, char** /*argv*/)
{
const time_t ProblematicTP = 1048989600; // 03/30/2003 @ 2:00am (UTC)
print(system_clock::from_time_t(ProblematicTP - 1));
print(system_clock::from_time_t(ProblematicTP));
print(system_clock::from_time_t(ProblematicTP + 1));
print(system_clock::from_time_t(ProblematicTP + 3600));
return 0;
}
Compiled with boost 1.69, gcc 821 on fedora linux 29. Output:
1048989599: 2003-03-30 01:59:59.000000000 +0000
1048989600: 2003-03-30 03:00:00.000000000 +0000
1048989601: 2003-03-30 03:00:01.000000000 +0000
1048993200: 2003-03-30 03:00:00.000000000 +0000
I tested this also on VS2013 on Windows 10 and the problem occurred there as well, but instead of jumping to 3 o’clock, it jumped to 1 o’clock. It seems that the incorrect time display is affected by the local time zone. Therefore the above example may give correct results in some time zones and incorrect in others.
After using the debugger you can see that the problem arises from the use of the mktime function, which should operate only on local time, and in the code it does not: (boost 1.69, time_point_io.hpp:968).
if (gmtime_r(&t, &tm) == 0) failed = true;
tm.tm_isdst = -1;
(void)mktime(&tm);
After the call to gmtime_r, the tm struct has correct values (hour == 2), but after calling mktime its hour value equal to 3
Now that stopwatch is gone the "sublibs" file should be removed.
chrono.qbk
and reference.html
refer to BOOST_HAS_CLOCK_STEADY
but I think it's meant to be BOOST_CHRONO_HAS_CLOCK_STEADY
. The former is not defined anywhere.
boost/chrono/round.hpp :
The header file is referenced repeatedly.
`
#ifndef BOOST_CHRONO_ROUND_HPP
#define BOOST_CHRONO_ROUND_HPP
#include <boost/chrono/duration.hpp>
#include <boost/chrono/duration.hpp>
//#include <boost/chrono/typeof/boost/chrono/chrono.hpp>
`
As currently discussed on the mailing list, boost::chrono
has a poor interoperability story with the std::chrono
types. As a short term improvement, I'd like to add to_std_duration
, to_std_time_point
and to_boost_duration
, to_boost_time_point
functions to this library.
Any comments on this idea before I start working on a PR?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.