I have two UTC times, stored as "day:hour:minute:second:millisecond", and also as five integer variables for day, hour, minute, etc. I'd like to find the difference between the two times, with millisecond precision. How can this be done in C++?
2 Answers
To calculate time difference with millisecond precision:
Convert both timestamps to
std::chrono::system_clock::time_point
.struct std::tm thetime { .tm_sec = sec, .tm_min = min, .tm_hour = hour, .tm_mday = mday, .tm_mon = mon, .tm_year = year }; auto mytime = (std::chrono::system_clock::from_time_t(std::mktime(&thetime))) + std::chrono::milliseconds(msec);
Subtract the two resulting timestamps.
auto diffms = std::chrono::duration_cast<std::chrono::milliseconds(mytime2 - mytime1).count();
EDIT: this does not take into account leap seconds or daylight saving time. If you are interested in milliseconds, you should probably use a time scale which has neither of these (so neither local time nor UTC are good choices). If your date and time were derived from a "UTC" POSIX clock in the first place, you are probably good to go, since "UTC" POSIX clock doesn't account for leap seconds (and of course has no DST).

- 112,515
- 14
- 128
- 243
-
Note that this method does not account for leap years, leap seconds and other calendar shenanigans, so it gives potentially unexpected results for timespans that overlap with any such curiosities. – ComicSansMS Jul 06 '20 at 06:32
-
@ComicSansMS why do you think so? How would the documentation for `from_time_t` imply that? – n. m. could be an AI Jul 06 '20 at 08:34
-
On second thought, I'm not actually sure what happens with leap years, that might have been a brain fart on my side, so apologies for that. Leap seconds though are definitely not handled, this is due to how Posix defines the system clock and C++ [adopts that same behavior](https://en.cppreference.com/w/cpp/chrono/system_clock). For the full messy story, see [one of Howard Hinnant's many brilliant answers on this topic](https://en.cppreference.com/w/cpp/chrono/system_clock). I agree that many apps will not care about this, but you better make sure yours don't before copy-pasting this. – ComicSansMS Jul 06 '20 at 08:51
-
@ComicSansMS Leap years definitely work but leap seconds and DST indeed may or may not. (If you are counting milliseconds you probably should not use either of these though) – n. m. could be an AI Jul 06 '20 at 09:34
How can I calculate a precise time difference (C++)?
On Linux, read time(7) and follow the hyperlinks there. To parse a time with C, use strptime(3). To convert it and format it to a string, use strftime(3). And both could be called from C++ code (use extern "C"
).
C and C++ are different languages. See also this.
the original question was tagged both C and C++
For C, read the Modern C book and, for Linux, Advanced Linux Programming then syscalls(2).
For C++, read Programming in C++.
you could want to use the <chrono>
standard header.
Classes and functions in that header enable you to compute that difference.
When compiling your code with GCC, enable all warnings and debug info. So use gcc
or g++
with -Wall -Wextra -g
and learn to use GDB.
On Linux, you'll find useful open source libraries, such a Glib, POCO, Qt, GtkMM and tools like JSON or SWIG....
Please look on github or gitlab for some source code which would inspire you.
I'd like to find the difference between the two times, with millisecond precision.
This could be difficult. Your hardware might not have a millisecond precision. If it is connected to the Internet, consider using some NTP service. If it is not connected, expect the clock to drift to more than a millisecond in a few weeks, unless you take very specific precautions or buy costly hardware.

- 223,805
- 18
- 296
- 547
-
1Almost nothing in your answer addresses the actual question. You talk about Unix specific time functions (without really explaining how they relate to the problem), C++ books and compilers, open-source libraries and NTP. The question is about the time difference of two UTC timestamps in C++. It's certainly a number of useful links, but not much that will be of immediate benefit of someone trying to solve the original problem. – ComicSansMS Jul 05 '20 at 05:01