Hacker News Reader

Comment by mynegation | Hacker News Reader

“int currentTimeMs” - whoa, I wish the compiler stop me there.

Yeah, you pretty much need to treat a millisecond timestamp as an opaque value, only using the Int you get when you subtract two of them. Doing that completely avoids the issues from timestamps being negative or wrapping around.

I've seen games that crash if your timestamps were negative. So if your computer has been on for a while, and a game isn't running properly, reboot.

The most recent C++ standards have become extreme with this. A time point from the filesystem is a different type to a time point from the OS, which has a different valid range.

I was intrigued by this, and looked up:

https://en.cppreference.com/w/cpp/chrono

Yeah, it is a bit chaotic.

...but, given that there often isn't just one "a time point from the OS", and thinking about the difference clock types on Linux (CLOCK_REALTIME, CLOCK_MONOTONIC, CLOCK_BOOTTIME, etc...[0]), clocks and calendars are just messy. If you try and simplify them, you miss some edge cases which always end up being important to someone.

I guess there are just a bunch of tradeoffs that need to be made, and no matter which ones anyone makes, a lot of other people would have made different ones.

[0] https://manpages.debian.org/bookworm/manpages-dev/clock_getr...

Following my initial, post-compiler-upgrade disgust, I do think it's a wise tradeoff. I can't use clock_cast yet - so the workarounds are kludgy - but it's that kludge that itself tells you you're dealing with something complex.

Reply on news.ycombinator.com