portable way to store milliseconds with chrono - c++

Question

I've a code as follows -
int main(){
....
auto time = std::chrono::system_clock::now().time_since_epoch() / std::chrono::milliseconds(1);
....
return 0;
}
The variable time here gives output as l with typeid().name() method, but is it safe to assume that if I replace auto with long type, the variable will still store the correct amount of milliseconds across different machines?
I need it because I cannot specify auto as type in class members, since they aren't constexpr or static where it might've been possible. And my intent is to send the data to browser where I can do var d = new Date(time) and it displays correct time. The communication part has been figured out via json format, I'm only stuck at how to store it correctly across different systems.

Answer 1

[...] is it safe to assume that if I replace auto with long type, the variable will still store the correct amount of milliseconds across different machines?
No, you need a signed integer type of at least 45 bits, which long is not guarantee to be. You should use std::chrono::milliseconds::rep:
using namespace std::chrono;
milliseconds::rep time =
duration_cast<milliseconds>(system_clock::now().time_since_epoch()).count();
Also note that in term of portability, the system_clock's epoch is not guaranteed to be January 1st 1970 00:00:00 UTC by the standard (even if it is the case most of the time).

Answer 2

Both of the existing answers are good. But as long as you're in C++ I encourage you to make the data member of type:
std::chrono::time_point<std::chrono::system_clock, std::chrono::milliseconds>
I know this is an ugly mouthful, but it can easily be made prettier. It is also easy to use. And it will help prevent run time errors in your C++ code.
Make it prettier
I recommend this templated using:
template <class Duration>
using sys_time = std::chrono::time_point<std::chrono::system_clock, Duration>;
Now you can make your data member have type:
sys_time<std::chrono::milliseconds> time_;
This is much more readable, and it exactly preserves the semantics that you are storing a time point, not an arbitrary number, or the number of calories in grapefruit.
Type Safety
Let's say six months from now you are re-visiting this code and you write:
auto z = x.time_ + y.time_;
If you had previously decided to give time_ type std::int64_t, or std::chrono::milliseconds::rep, then the above new line of code compiles and creates a run time error. It makes no sense to add two points in time. Tomorrow + today is nonsensical.
However if you had previously decided to give time_ type sys_time<milliseconds> as I suggest, the above line of code creating z does not compile. The type system has detected the logic error at compile time. Now you are forced to immediately re-visit your logic and discover why you are attempting to add two time points. Maybe it was just a type-o and you meant to subtract them (which is logical, compiles, and results in a duration of type milliseconds).
Ease of use
You can assign now() to your time_ data member with this simple syntax:
using namespace std::chrono;
time_ = time_point_cast<milliseconds>(system_clock::now());
Now time_ is just another system_clock-based time_point but with a precision of milliseconds. For outputting to json you can get the internal signed integral value with:
json_stream << time_.time_since_epoch().count();
For parsing in from json you can:
std::int64_t temp;
json_stream >> temp;
time_ = sys_time<milliseconds>{milliseconds{temp}};

Answer 3

Your approach will work and is portable, but i suggest to use a more straightforward approach for counting milliseconds:
std::chrono::duration_cast<std::chrono::milliseconds>(std::chrono::system_clock::now().time_since_epoch()).count()
This will definitely work because .count() returns a std::chrono::milliseconds::rep which is "A signed integral type of at least 45 bits" and should fit in long.
Note: it is not guaranteed that system_clock will have millisecond resolution. But in any case you will get result in milliseconds.
Side note: I can be good to utilize using namespace std::chrono; because this will reduce code length significantly.