std::chrono time_point now() cycling period leads to possible negative duration

[kala7a]

I'm facing an issue where std::chrono::time_point seems to cycle from around: 922318998926 to around -922324948144 which seems to result in possibility delta between time_point to become negative value.

Tried both with high_resolution_clock and steady_clock

Here is a code snipped that can recreate the issue:

Tried to print time_point from now(), time_since_epoch() also duration_cast of time_since_epoch() from both high_resolution_clock and steady clock but all seems to provide similar results.

#include <iostream>
#include <chrono>
#include <thread>
#include <cstdint>

using namespace std::chrono;

int main() 
{
    const auto targetDuration = milliseconds(16);

    auto startTick = high_resolution_clock::now();
    auto startTickDuration = startTick.time_since_epoch();
    auto startTickNanoseconds = duration_cast<nanoseconds>(startTickDuration).count();

    auto startTickSteady = steady_clock::now();
    auto startTickSteadyDuration = startTickSteady.time_since_epoch();
    auto startTickSteadyNanoseconds = duration_cast<nanoseconds>(startTickSteadyDuration).count();

    while (true) 
    {
        auto loopStart = high_resolution_clock::now();

        auto currentTick = high_resolution_clock::now();
        auto currentTickDuration = currentTick.time_since_epoch();
        auto currentTickNanoseconds = duration_cast<nanoseconds>(currentTickDuration).count();

        auto currentTickSteady = steady_clock::now();
        auto currentTickSteadyDuration = currentTickSteady.time_since_epoch();
        auto currentTickSteadyNanoseconds = duration_cast<nanoseconds>(currentTickSteadyDuration).count();
        
        const duration<double, std::milli> deltaTime = (currentTick - startTick);
        const double fl_delta = deltaTime.count();

        const duration<double, std::milli> deltaTimeSteady = (currentTickSteady - startTickSteady);
        const double fl_deltaSteady = deltaTimeSteady.count();

        std::cout << "fl_delta " << fl_delta << 
            " fl_deltaSteady " << fl_deltaSteady <<
            " startTickNanoseconds: " << startTickNanoseconds <<
            " currentTickNanoseconds: " <<  currentTickNanoseconds <<
            " startTickDuration: " << startTickDuration.count() << " ticks " <<
            " currentTickDuration: " << currentTickDuration.count() << " ticks " <<
            " startTickSteadyNanoseconds: " << startTickSteadyNanoseconds <<
            " currentTickSteadyNanoseconds: " <<  currentTickSteadyNanoseconds <<
            " startTickSteadyDuration: " << startTickSteadyDuration.count() << " ticks " <<
            " currentTickSteadyDuration: " << currentTickSteadyDuration.count() << " ticks " <<
            std::endl;

        if (fl_delta < 0.0)
        {
            std::cout << "Potential error detected" << std::endl;
        }

        if (fl_deltaSteady < 0.0)
        {
            std::cout << "Potential error detected" << std::endl;
        }

        // Sleep to maintain 16ms loop timing
        auto loopEnd = high_resolution_clock::now();
        auto elapsed = duration_cast<milliseconds>(loopEnd - loopStart);
        auto sleepTime = targetDuration - elapsed;

        if (sleepTime > milliseconds(0)) {
            std::this_thread::sleep_for(sleepTime);
        }
    }

    return 0;
}

Below you can see logs before issue happens where for example currentTickSteadyNanoseconds changes from 922318998926 to -922324948044 and my delta becomes negative value: -269912.

fl_delta 1.57473e+06 fl_deltaSteady 1.57473e+06 startTickNanoseconds: -652412668173 currentTickNanoseconds: 922318998826 startTickDuration: -652412668173 ticks currentTickDuration: 922318998826 ticks startTickSteadyNanoseconds: -652412668173 currentTickSteadyNanoseconds: 922318998926 startTickSteadyDuration: -652412668173 ticks currentTickSteadyDuration: 922318998926 ticks

fl_delta -269912 fl_deltaSteady -269912 startTickNanoseconds: -652412668173 currentTickNanoseconds: -922324948144 startTickDuration: -652412668173 ticks currentTickDuration: -922324948144 ticks startTickSteadyNanoseconds: -652412668173 currentTickSteadyNanoseconds: -922324948044 startTickSteadyDuration: -652412668173 ticks currentTickSteadyDuration: -922324948044 ticks

For me strange is that these numbers seems to overflow far before reaching 64 bit int number or double limits. Which makes this issue to appear in this code just after 30-60 min run on my PC.

Same code tested with:

• visual studio 2019 compiler
• mingw gcc (part of scoop Windows packages)
• gcc on ubuntu 20.04
• clang on ubuntu 20.04
  seems to not cause this issue or at least not after 30-60 min run. Where I can see that ticks can reach much bigger values.

Tested with: llvm-mingw-20250826-msvcrt-x86_64

[mstorsjo]

I haven't had time to look into this yet, but I just wanted to comment to say that I'm aware of the issue report.

You could try to get more visibility about the issue by reposting it at http://github.com/llvm/llvm-project/issues, framing it as a general libcxx on windows issue.