3 ms·

If you're using systemtime for anything else than dumping into logs as timestamps, you're doing it wrong. Mocking system clocks for testing just confirms that

by loopz 6y ago

If you're using systemtime for anything else than dumping into logs as timestamps, you're doing it wrong. Mocking system clocks for testing just confirms that truth. If you can't think of an alternative to using some variation of systemtime function for business operational rules, I'm not really sure what you're pushing to production.

TheDong 6y ago
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.
- loopz 6y ago
  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.
  - TheDong 6y ago
    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.
    - loopz 6y ago
      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.

by loopz 6y ago

TheDong 6y ago

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.

loopz 6y ago
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.
- TheDong 6y ago
  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.
  - loopz 6y ago
    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.