3 ms·
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), yo
by 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 agoWe'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 agoFair 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.