C++ Logo


Advanced search

chrono system_clock to_time_t/from_time_t unexpected integer overflow

From: Igor Ingultsov <ingultsov_at_[hidden]>
Date: Thu, 7 Oct 2021 14:04:54 +0200

recently I've stumbled upon an unexpected issue which is also not really
documented (or am I wrong?).

Consider the code:

    // time_t for year 2500
    time_t t = 16756675140; // which is ok on many systems as time_t is
usually now 64bit
    auto tp = std::chrono::system_clock::from_time_t(t);
    std::cout << std::chrono::system_clock::to_time_t(tp);

I would naively expect identity
  t == to_time_t(from_time_t(t));

but what happens in reality is, time_t as seconds is being put into the
time_point with resolution (on Linux/libstdc++) of nanoseconds, which has
an upper limit of around Year 2262.

Is there any reason, why there would be an implicit conversion from time_t
to time_point with nanoseconds duration?

As far as I know, time_t is everywhere the amount of seconds since epoch
(and in C++20 anyway since 1970).

The solution could be:
  *std::system_clock::from_time_t* should return *time_point* of the *same
resolution as time_t* in current implementation.

Problem ist however, there would be no guard against:
  time_point<seconds> ts = from_time_t(t);
  time_point<nanoseconds> tns = ts; // ok from perspective of
time_point/duration cast, as we don't loose precision, but we could still
silently loose resolution.

Do you have any ideas how this could be changed?

Best regards
Igor Ingultsov

Received on 2021-10-07 07:05:19