time: suspending the host inconsistently pause timers based on the OS

[sn-benjamin-phan]

What version of Go are you using (go version)?

$ go version
go version go1.23.1 windows/amd64

We develop the go program on mac, but then build an executable for Windows, so I manually filled in the go version, instead of using the go version command (it was populating with darwin since I ran "go bug" on my mac laptop).

Does this issue reproduce with the latest release?

Unsure, we only know that it is happening on 1.23.1. It would take considerable effort to test with the latest version of go, given our development cycle.

What operating system and processor architecture are you using (go env)?

We develop the go program on mac, but then build an executable for Windows, so the go env details may be inconsistent with the environment when our program is running on the Windows laptop.

go env Output

$ go env
AR='ar'
CC='clang'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='clang++'
GCCGO='gccgo'
GO111MODULE=''
GOAMD64='v1'
GOARCH='amd64'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/Users/benjamin.phan/Library/Caches/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/Users/benjamin.phan/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/vc/44qy7_ws2hv091hzcd3tsggm0000gp/T/go-build1022912774=/tmp/go-build -gno-record-gcc-switches -fno-common'
GOHOSTARCH='amd64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMOD='/Users/benjamin.phan/git/feature/agent-now/go.mod'
GOMODCACHE='/Users/benjamin.phan/go/1.24.4/pkg/mod'
GONOPROXY='code.devsnc.com'
GONOSUMDB='code.devsnc.com'
GOOS='darwin'
GOPATH='/Users/benjamin.phan/go/1.24.4'
GOPRIVATE='code.devsnc.com'
GOPROXY='https://golang.devsnc.com/repository/snc-go-modules/'
GOROOT='/Users/benjamin.phan/.anyenv/envs/goenv/versions/1.24.4'
GOSUMDB='sum.golang.org'
GOTELEMETRY='local'
GOTELEMETRYDIR='/Users/benjamin.phan/Library/Application Support/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/Users/benjamin.phan/.anyenv/envs/goenv/versions/1.24.4/pkg/tool/darwin_amd64'
GOVCS=''
GOVERSION='go1.24.4'
GOWORK=''
PKG_CONFIG='pkg-config'
GOROOT/bin/go version: go version go1.24.4 darwin/amd64
GOROOT/bin/go tool compile -V: compile version go1.24.4
uname -v: Darwin Kernel Version 24.5.0: Tue Apr 22 19:53:26 PDT 2025; root:xnu-11417.121.6~2/RELEASE_X86_64
ProductName:		macOS
ProductVersion:		15.5
BuildVersion:		24F74
lldb --version: lldb-1500.0.404.7
Apple Swift version 5.10 (swiftlang-5.10.0.13 clang-1500.3.9.4)

What did you do?

Run the program on a Windows laptop.
The program creates a time package timer that should fire after 5 minutes. When the timer fires, print the current time.
In another goroutine, log periodically to see exactly when the program was suspended due to the sleep.
After one minute, put the laptop to sleep from the Windows Start menu.
After 5 minutes, wake the laptop up.

package main

import (
 "fmt"
 "time"
)

func main() {
 timer := time.NewTimer(300 * time.Second) // 5 minutes
 go func() {
  ticker := time.NewTicker(1 * time.Second)
  defer ticker.Stop()
  for ticks := 1; ticks <= 300; ticks++ {
   <-ticker.C
   fmt.Printf("ticker: %d\n", ticks)
  }
 }()
 <-timer.C
 fmt.Println("timer finished")
}

What did you expect to see?

The timer should wait another 4 minutes before firing since it was set to fire after 5 minutes, and it only ran for 1 minute before the laptop was put to sleep.

What did you see instead?

The timer will fire immediately after the go program is unsuspended.

We noticed that this issue was not reproducible when running the same steps on a mac laptop. The timer would continue where it left off after waking up from the sleep on mac.

[gabyhelp]

Related Issues

• runtime: Timer buckets may get "stuck" for long periods of time after Windows 8/10 systems wake from sleep #31528 (closed)
• time: Sub is inaccurate after computer has slept #23178 (closed)
• time: NewTimer firing later if computer sleeps, how to use wall clock? #35012
• runtime: time.Sleep() wakes up too early #48214 (closed)
• time: Sleep(1 * time.Nanosecond) pauses at least 1.9ms on Windows 10 or Windows 7 #29485 (closed)
• runtime: time.Sleep problem on Windows 10, but not Windows 7 or Linux #61042 (closed)
• time: After delay 10s occasionally #21746 (closed)
• runtime: Windows "high-resolution" timer seems to do the opposite #51530 (closed)
• time: timer gets significantly delayed during long time GC #45632

Related Code Changes

• runtime: monitor for suspend/resume to kick timeouts

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[Jorropo]

I am not sure what is the correct behavior, if anything the macos behavior is the one I find I find surprising.

---

cc @rsc as per https://dev.golang.org/owners

[Jorropo]

I would like to test on my linux machines but unsurprisingly resume from suspend does not works ✨.

[Jorropo]

It looks like it's OS dependent and time does not try to deal with it:

On some systems the monotonic clock will stop if the computer goes to sleep. ...

Altho this text speaks about the time.Time type; not timers but it is the only documentation about the host suspending / sleeping I could find, so probably needs to be expanded there.

[ldemailly]

cc @egonelbre for thoughts. I think it's good that the timer fires as close as possible (even in the past) to what was initially schedule, ie real clock time and not paused time. but I don't know if that's consistent with say what happens if someone adjusts the clock and/or leap seconds etc (probably as a counter, a daylight savings change should probably not trigger nor delay timers)

In general it's easier for an app to skip an "extra" firing than to miss one so it seems we should air on the side of firing sooner (like on linux I guess, unlike on macos? what about windows?)

[egonelbre]

I would say that timers should be based on real time. There definitely are use cases for "non-suspended time timers" and "system clock timers", but those are more likely to introduce bugs with regards to timers not triggering soon enough or not at all due to system clock error. So to me Windows behaviour seems correct, and if there's a need for Mac behaviour it should be some new different API (either by listening to suspend/wake events or some kind of NewUnsuspendedTimer).

[ianlancetaylor]

The proposal at #36141 may be relevant.