Better yet, use std::chrono. Yes, it's C++. But this is an example of how properly applied bits from C++ can make things easier to reason about and type-safe, rather than "let's avoid C++ as much as possible".
No ambiguity for the programmer as to what the underlying units are, and no unnecessary int/float conversions. All the book-keeping and conversions are taken care of by the compiler with zero run-time size or perf overhead.
std::chrono is a terribly overengineered API even for the STL, and many game companies have banned parts or all of the STL for good reasons (usually not std::chrono related though).
Using an uint64_t (instead of uint32_t or double) to carry "opaque ticks", and a handful conversion function to convert to real-world time units is fine and just a few lines of code.
it would still be an offset much less than the loss of precision by storing int milliseconds.
There are also some techniques for dealing with the time inaccuracies, although I feel those aren't widely known.
This can have surprising and sometimes unpleasant consequences; see https://0.30000000000000004.com