time module: Return value of `sys_mono_now` is not the counter value.

[quaesitor-scientiam]

Describe the bug

Current return value is not the actual value but a calculated value that leads to rollover causing negative time values. Examination of the various platforms and backends show inconsistent handling. I can show each example here but not sure if that is needed.

Reproduction Steps

import time


wait_times := [
	5*time.minute + 52*time.second,
	3*time.minute + 14*time.second,
	44*time.second,
	26*time.second,
	1*time.minute + 58*time.second,
	4*time.second,
	4*time.minute + 27*time.second,
	3*time.minute + 24*time.second,
	5*time.minute + 3*time.second,
	1*time.minute + 56*time.second,
	1*time.minute + 8*time.second,
	12*time.second,
	10*time.minute + 8*time.second,
]
mut wt := 0
mut sw := time.new_stopwatch()
for {
	println('SW: ${sw}')
	time.sleep(wait_times[wt])
	wt++
	sw.stop()
	if sw.end < sw.start {
		println('Negative: ${sw}')
		break
	}
	println('Elapsed: ${sw.elapsed()}')
	if wt == 13 {
		println('Success')
		break}

	sw.start()
}

Expected Behavior

No rollover of sys_mono_now values causing negative elapsed values

Current Behavior

Start SW: time.StopWatch{
    elapsed: 0
    start: 323682500
    end: 0
}
Stopped SW: time.StopWatch{
    elapsed: 0
    start: 323682500
    end: 373885451300
}
Start SW: time.StopWatch{
    elapsed: 0
    start: 373885759500
    end: 0
}
Stopped SW: time.StopWatch{
    elapsed: 0
    start: 373885759500
    end: 569315427200
}
Start SW: time.StopWatch{
    elapsed: 0
    start: 569315652400
    end: 0
}
Stopped SW: time.StopWatch{
    elapsed: 0
    start: 569315652400
    end: 606243234400
}
Start SW: time.StopWatch{
    elapsed: 0
    start: 606243434100
    end: 0
}
Stopped SW: time.StopWatch{
    elapsed: 0
    start: 606243434100
    end: 627761309800
}
Start SW: time.StopWatch{
    elapsed: 0
    start: 627761517700
    end: 0
}
Stopped SW: time.StopWatch{
    elapsed: 0
    start: 627761517700
    end: 719225597500
}
Start SW: time.StopWatch{
    elapsed: 0
    start: 719225799200
    end: 0
}
Stopped SW: time.StopWatch{
    elapsed: 0
    start: 719225799200
    end: 722222679800
}
Start SW: time.StopWatch{
    elapsed: 0
    start: 722222906800
    end: 0
}
Stopped SW: time.StopWatch{
    elapsed: 0
    start: 722222906800
    end: 989538689700
}
Start SW: time.StopWatch{
    elapsed: 0
    start: 989538914700
    end: 0
}
Stopped SW: time.StopWatch{
    elapsed: 0
    start: 989538914700
    end: 1133303427200
}
Start SW: time.StopWatch{
    elapsed: 0
    start: 1133303712700
    end: 0
}
Stopped SW: time.StopWatch{
    elapsed: 0
    start: 1133303712700
    end: 1453101667500
}
Start SW: time.StopWatch{
    elapsed: 0
    start: 1453101896700
    end: 0
}
Stopped SW: time.StopWatch{
    elapsed: 0
    start: 1453101896700
    end: 1530729617000
}
Start SW: time.StopWatch{
    elapsed: 0
    start: 1530729890300
    end: 0
}
Stopped SW: time.StopWatch{
    elapsed: 0
    start: 1530729890300
    end: 1578334624700
}
Start SW: time.StopWatch{
    elapsed: 0
    start: 1578334857700
    end: 0
}
Stopped SW: time.StopWatch{
    elapsed: 0
    start: 1578334857700
    end: 1587515723400
}
Start SW: time.StopWatch{
    elapsed: 0
    start: 1587515949300
    end: 0
}
Stopped SW: time.StopWatch{
    elapsed: 0
    start: 1587515949300
    end: 187768837029
}

The last one generated negative elapsed time

Possible Solution

This needs a discussion because fixing to return the actual value has ramifications for whole lot of V I think. I have a working solution but have not tested the ecosystem of V.

Additional Information/Context

No response

V version

V 0.5.0 b9e9192

Environment details (OS name and version, etc.)

|V full version      |V 0.5.0 b9e9192b2b229c82b097911e2f64ea420a1c6c68
|:-------------------|:-------------------
|OS                  |windows, Microsoft Windows 11 Pro 26200 64-bit
|Processor           |24 cpus, 64bit, little endian, AMD Ryzen 9 5900X 12-Core Processor
|Memory              |72.83GB/127.92GB
|                    |
|V executable        |S:\repo\vlang2\v.exe
|V last modified time|2026-01-05 04:56:05
|                    |
|V home dir          |OK, value: S:\repo\vlang2
|VMODULES            |OK, value: C:\Users\john3\.vmodules
|VTMP                |OK, value: S:\temp\v_0
|Current working dir |OK, value: S:\vProjects\testit
|                    |
|env VFLAGS          |"-g"
|Git version         |git version 2.52.0.windows.1
|V git status        |0.5-23-gb9e9192b-dirty
|.git/config present |true
|                    |
|cc version          |N/A
|gcc version         |gcc (MinGW-W64 x86_64-ucrt-posix-seh, built by Brecht Sanders, r8) 13.2.0
|clang version       |N/A
|msvc version        |N/A
|tcc version         |tcc version 0.9.27 (x86_64 Windows)
|tcc git status      |thirdparty-windows-amd64 b425ac82
|emcc version        |N/A
|glibc version       |N/A

Note

You can use the 👍 reaction to increase the issue's priority for developers.

Please note that only the 👍 reaction to the issue itself counts as a vote.
Other reactions and those to comments will not be taken into account.

[quaesitor-scientiam]

Current implementation from time_windows.c.v

// sys_mono_now returns a *monotonically increasing time*, NOT a time adjusted for daylight savings, location etc.
pub fn sys_mono_now() u64 {
	tm := u64(0)
	C.QueryPerformanceCounter(voidptr(&tm)) // XP or later never fail
	return (tm - start_time) * 1000000000 / freq_time
}

In the failure output the StopWatch.start value comes from a call to the method above. Instead of just returning the counter value tm it performs an elapsed calculation adjusting the output by multiplying the difference by 1 billion (1,000,000,000). Hence why a longer running process rolls over in just 25 minutes producing a time value smaller that the start value when calling StopWatch.stop which calls the same function above.

My question why even do this. Searching the Web can find ZERO examples of querying Monotonic time values for consistent increasing time values. I wonder why this hasn't been noticed before now. I concluded focus was on shorter times. Doesn't explain the adjustment to the result value. Perhaps someone who been here longer can explain a reasoning for the adjustment.

To fix the issue I commented out the current return line and used return tm instead.

So began to wonder how its handled elsewhere in the V space and found the following:

// Note: vpc_now is used by `v -profile` .
// It should NOT call *any other v function*, just C functions and casts.
@[inline]
fn vpc_now() u64 {
	tm := u64(0)
	C.QueryPerformanceCounter(voidptr(&tm))
	return tm
}

Then in time_nix_c.v the 1 billion adjustment but not in the windows version above. Inconsistent?

// Note: vpc_now is used by `v -profile` .
// It should NOT call *any other v function*, just C functions and casts.
@[inline]
fn vpc_now() u64 {
	ts := C.timespec{}
	C.clock_gettime(C.CLOCK_MONOTONIC, &ts)
	return u64(ts.tv_sec) * 1_000_000_000 + u64(ts.tv_nsec)
}

// sys_mono_now returns a *monotonically increasing time*, NOT a time adjusted for daylight savings, location etc.
pub fn sys_mono_now() u64 {
	$if macos {
		return sys_mono_now_darwin()
	} $else {
		ts := C.timespec{}
		C.clock_gettime(C.CLOCK_MONOTONIC, &ts)
		return u64(ts.tv_sec) * 1_000_000_000 + u64(ts.tv_nsec)
	}
}

Then in time_darwin.c.v we have the following. Do not not understand what's being produce would need to research darwin space

// Note: vpc_now_darwin is used by `v -profile` .
// It should NOT call *any other v function*, just C functions and casts.
@[inline]
fn vpc_now_darwin() u64 {
	tm := C.mach_absolute_time()
	if time_base.denom == 0 {
		unsafe {
			C.mach_timebase_info(&time_base)
		}
	}
	return (tm - start_time) * time_base.numer / time_base.denom
}

fn sys_mono_now_darwin() u64 {
	tm := C.mach_absolute_time()
	if time_base.denom == 0 {
		unsafe {
			C.mach_timebase_info(&time_base)
		}
	}
	return (tm - start_time) * time_base.numer / time_base.denom
}

Then in time_js.js.v we have. You see someone commented out the adjustments already.

// sys_mono_now returns a *monotonically increasing time*, NOT a time adjusted for daylight savings, location etc.
pub fn sys_mono_now() u64 {
	$if js_browser {
		mut res := u64(0)
		#res = new u64(Math.floor(window.performance.now() * 1000000))

		return res
	} $else $if js_node {
		mut res := u64(0)
		#res.val = $process.hrtime.bigint()

		return res
	} $else {
		mut res := u64(0)
		#res = new u64($sys_mono_new_Date() * 1000000)

		return res
	}
}

Scan of vlib for use of sys_mono_now is used in many_writers_and_receivers_on_1_channel.v, 'pool\connection.vScan ofvlibfor use ofvpc_nowis used inprofile.v maybe 'markused.v

To get elapsed working correctly in 'stopwatch.v` was changed from

// elapsed returns the Duration since the last start call.
pub fn (t StopWatch) elapsed() Duration {
	if t.start > 0 {
		if t.end == 0 {
			return Duration(i64(sys_mono_now() - t.start + t.elapsed))
		} else {
			return Duration(i64(t.end - t.start + t.elapsed))
		}
	}
	return Duration(i64(t.elapsed))
}

to this where the web shows how its done. It now returns nanoseconds. However the last return doesn't make sense doing a recursive call to elapsed again unless the thought is to repeat until start gets set?

// elapsed returns the Duration since the last start call in nanoseconds.
pub fn (t StopWatch) elapsed() Duration {
	if t.start > 0 {
		if t.end == 0 {
			return Duration(calculate_nanoseconds((sys_mono_now() - t.start)))
		} else {
			return Duration(calculate_nanoseconds((t.end - t.start)))
		}
	}
	return Duration(i64(t.elapsed))
}

Added new method to calculate nanoseconds based on a given set of ticks in the time.windows.c.v

pub const billionth = 1000000000

pub fn calculate_nanoseconds[T](ticks T) T {
	return u64(ticks * billionth / freq_time)
}

I await feedback on this change thanks

[spytheman]

However the last return doesn't make sense doing a recursive call to elapsed again unless the thought is to repeat until start gets set?

the last return is just getting the value of the stored property, without invoking the method with the same name, so it does not recurse.

[spytheman]

the overflow happens here: u64(ticks * billionth / freq_time), because the ticks is first multiplied by the big number, which overflows, and only then the result is divided; in the PR, this is avoided, by normalizing both of those coefficients so that they are not so large anymore, which limits the overflow situation a lot (it will happen for durations > 5.8 years)

[quaesitor-scientiam]

How do you know if it happens for greater than 5.8 years?