related / dup of #35012 ?

The time value comes from a call to mach_absolute_time. If that returns a value that sometimes resets to zero, that sounds like an operating system bug. If you are able to repeat the problem, perhaps you could modify nanotime1 to report whether nanotime_trampoline returns an r.t value of 0. That would point to the operating system as the problem, in which case it's not clear what Go can do.

This sounds a bit like libuv/libuv#2891. What version of Darwin are you running?

The time value comes from a call to mach_absolute_time. If that returns a value that sometimes resets to zero, that sounds like an operating system bug. If you are able to repeat the problem, perhaps you could modify nanotime1 to report whether nanotime_trampoline returns an r.t value of 0. That would point to the operating system as the problem, in which case it's not clear what Go can do.

This sounds a bit like libuv/libuv#2891. What version of Darwin are you running?

14.4.1

I've tested with my friend and found that using simple code as this playground can't reproduce the issue. But this issue can be reproduced using our service code.

I'm going to write a simple gin service to try to reproduce this, and print mach_absolute_time

Seems to be related to this issue: libuv/libuv#2891 as @ianlancetaylor mentioned

I write another simple code for reproducing this:

package main

/*
#cgo LDFLAGS: -framework CoreFoundation -framework IOKit
#include <mach/mach_time.h>

uint64_t mach_absolute_time_wrapper() {
    return mach_absolute_time();
}
*/
import "C"
import (
	"time"

	"github.com/gin-gonic/gin"
)

var expiresAt = time.Now().Add(time.Hour * 3)

func machAbsoluteNano() uint64 {
	return uint64(C.mach_absolute_time_wrapper())
}

func toDur(nano uint64) time.Duration {
	return time.Duration(nano) * time.Nanosecond
}

func main() {
	r := gin.Default()
	r.GET("/time", handler)
	r.Run(":8080")
}

func handler(c *gin.Context) {
	now := time.Now()
	isBefore := now.Before(expiresAt)
	uptime := machAbsoluteNano()
	c.JSON(200, gin.H{
		"isBefore":             isBefore,
		"mach_absolute_time()": uptime,
		"now":                  now.String(),
		"expiresAt":            expiresAt.String(),
		"uptimeDuration":       toDur(uptime).String(),
	})
}

output:

$ curl localhost:8080/time -s | jq
{
  "expiresAt": "2024-04-19 17:14:28.654548 +0800 CST m=+10800.003901671",
  "isBefore": true,
  "mach_absolute_time()": 76197193801457,
  "now": "2024-04-19 14:15:36.137978 +0800 CST m=+67.486527117",
  "uptimeDuration": "21h9m57.193801457s"
}

I'll check this next morning (about 18~20hrs later)

Maybe there is no such clock reset things. It just stopped while sleep. For example, var expiresAt = time.Now().Add(time.Hour * 3) means expiresAt: m=+10800, and now: m=+67. If I let the computer sleep imediatly in 1 sec, then next day, new now is surely not before expiresAt, but due to the monotonic clock stopped, m of now may still equal to +67, which is smaller then +10800, cause now is before expires (67 < 10800).

Although the stopping of a monotonic clock does not destroy its monotonicity, it may introduce bugs in this case.

So in macos(or other OS that may stop the monotonic clock), we may using raw mach_absolute_time() to avoid this bug.

To make this reproducing more clearly, I'll modify expiresAt to tomorrow 6 a.m UTC+8 (about 15hrs later), and some data:

$ curl localhost:8080/time -s | jq
{
  "expiresAt": "2024-04-20 06:00:23.307705 +0800 CST m=+51720.003813063",
  "isBefore": true,
  "mach_absolute_time()": 80009874232411,
  "now": "2024-04-19 15:38:26.38051 +0800 CST m=+3.076554055",
  "uptimeDuration": "22h13m29.874232411s"
}

Next morning after 8:00 am, I'll fire another curl, and expect that due to monotonic clock stopping during sleep, new now's m will smaller then expiresAt m=+51720.003813063

The key point is, if you are going to sleep 4hrs, the value time.Now().Add(someInterval), it's monotonic clock (the m value) should also minus 4hrs:
Before sleep, expiresAt monotonic clock is 10hrs
After sleep 4hrs, expiresAt monotonic clock should minus 4hrs, to 6hrs, because after sleep, all generated Time struct's monotonic clocks are lost 4hrs for ever.

This issue may impact App written in go, like created by https://github.com/wailsapp/wails

As mentioned in this issue: #23178, this is an expected behavior.
https://pkg.go.dev/time#hdr-Monotonic_Clocks

On some systems the monotonic clock will stop if the computer goes to sleep. On such a system, t.Sub(u) may not accurately reflect the actual time that passed between t and u.

For my case, I can use t.Round(0) to remove monotonic clock, and make all things happy.

Maybe I could add some comment to t.Sub, t.Add, t.Before, t.After, to warn people about this trap

Added some notes. PR here: #66922

Change https://go.dev/cl/580515 mentions this issue: time: add notes about monotonic time paused