[fhd2]

Timestamps are used for a lot of scheduling tasks that need to be reasonably precise. So an event happening one second earlier than expected, or even twice, could be a problem I suppose. Not exactly impossible to deal with, but I guess lots of people screw it up? Haven't really worked on systems where this _truly_ matters.

[spookie]

Synchronization between computers is hard. https://www.gnu.org/software/coreutils/manual/coreutils.html...

[sohkamyung]

Could it matter for high-frequency trading? Since these trades occur in milliseconds, I presume trading being off by a second would be considered very damaging.

[gpderetta]

It is not just very damaging, it also has legal implications. For example MIFID II regulations require at least 100us resolution for trade reporting. In practice PTP and GPS clocks are a requirement.

[rapsey]

Scheduling tasks on a system is done using UTC/local time which the system keeps accurate. Unix time is not used for that.

[butlerm]

I am not aware of any operating system kernel that schedules tasks or timer expiration using a strict definition of UTC. Unix time is the most common, and local monotonic (non-decreasing) clocks are becoming common for that as well.

Of course there are application level schedulers that use wall clock time in UTC format, and if you set the clock back your task may run twice, which is a more serious real world problem than running twice around a leap second. That is why no one who is not attached to civil time should use UTC or Unix time for short duration timer expiration in particular.