Go doesn't differentiate the program's monotonic time from systemtime in terms of the package interface given.

time.Now in go returns both the system time (i.e. if you do '.Seconds' or 'String' on that time, you get a wall clock time), but also returns a monotonic time (if you subtract or compare two times, it uses monotonic time).

Go's time package isn't just systemtime, and there's really not an alternative to it in the language. You're arguing against a strawman.

I don't think you got my point though. If you're using timestamps for anything else than dumping into a logfile (or purely for displaying/cosmetic purposes), you're doing it wrong. Somewhere along the line, you could end up with a nasty surprise. Not thinking of clock drift or any kind of seasonal adjustments here.

Maybe you're using time-package right and avoiding the above, maybe not. Timestamp usage is best to avoid for anything business critical.

We're misunderstanding each other then.

I assumed this package about mocking time was _not_ about mocking timestamps but program behavior. For example, if I have a loop that says "every 20 seconds, do X", and I want to test that, I now have to mock time.

That's not about timestamps, that's about comparing monotonic clocks for "20s have elapsed".

The go time package doesn't just give you a timestamp to do something with, it also lets you compare times. That was my point.

It sounds like your original comment was arguing that mocking time isn't useful, so I assumed you meant all uses of time.

Fair enough. If you want to mock time differentials like that, I see that one could use something to mock that. However, what you probably ideally would want to mock are the order of events, and not certain language-specific stdlib-calls. Though would depend how explicit you want to define your domain.