Hacker News Reader

Comment by defrost | Hacker News Reader

Tinder dates and market moves, maybe.

Real time scientific, physics, and engineering data acquisition and processing applications? Goodness no.

Certainly nothing that might want to generate a waypoint heading update via a division of elapsed time. Not with those random UTC leap seconds that can go either way (although, until now, they've all fallen in one direction).

There's a reason serious real time real world data processing goes with epoch based time, lapsed time since <mark>, it has the nice feature of being monotonically increasing.

View on HN

Something which bugs me about UNIX time is that, contradictory to its colloquial name (epoch time), UNIX time does not increase linearly and does funny stuff on leap seconds.

Even CLOCK_MONOTONIC doesn’t increase linearly, it is affected by NTP updates.

Apparently newer Linux kernels support CLOCK_MONOTONIC_RAW which is not affected by NTP, but even that may not increase linearly: it’s not updated when the system is in standby.

Then there is also CLOCK_BOOTTIME which is monotonic and accounts for time spent in standby.

Neither of these seem to be POSIX standardised, though.

CLOCK_MONOTONIC is affected by NTP skewing but should still always increase monotonically (i.e. never decrease)

What happens if someone makes an honest mistake (or is just malicious) and makes their NTP server run fast?

It's system dependent but Linux will generally speed up or slow down the time advancement until the delta from adjtime(...) matches up:

https://linux.die.net/man/2/clock_gettime

   This clock is not affected by discontinuous jumps in the system time (e.g., if the system administrator manually changes the clock), but is affected by the incremental adjustments performed by adjtime(3) and NTP.

https://linux.die.net/man/3/adjtime

   If the adjustment in delta is positive, then the system clock is speeded up by some small percentage (i.e., by adding a small amount of time to the clock value in each second) until the adjustment has been completed. If the adjustment in delta is negative, then the clock is slowed down in a similar fashion.

UNIX time is _an_ example of a type of epoch time, with extra rules and conditions.

Not all epoch time counters are UNIX time though.

The usual case, when referring to an epoch time counter being used, is a uniform, increasing count of elapsed time in a standard fixed length unit (seconds, cycles, orbits, etc.).

I am fairly certain POSIX define a day to be exactly 86400 seconds for the matter of calendar conversions/calculations, and deliberately ignores leap seconds: https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1...

Reply on news.ycombinator.com