News for hackers. Stuff that matters.

A comment on Unix time is bad and needs replacement, not UTC. Parent comment

Re:Unix time is bad and needs replacement, not UTC by fhd2 on Wednesday November 23, 2022 @04:03AM (#33716792)
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.
[ Parent | on HN ]
Re:Unix time is bad and needs replacement, not UTC by spookie on Wednesday November 23, 2022 @04:11AM (#33716851)
Synchronization between computers is hard. https://www.gnu.org/software/coreutils/manual/coreutils.html...
[ Parent | on HN ]
Re:Unix time is bad and needs replacement, not UTC by sohkamyung on Wednesday November 23, 2022 @04:11AM (#33716852)
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.
[ Parent | on HN ]
Re:Unix time is bad and needs replacement, not UTC by gpderetta on Wednesday November 23, 2022 @05:22AM (#33717354)
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.
[ Parent | on HN ]
Re:Unix time is bad and needs replacement, not UTC by rapsey on Wednesday November 23, 2022 @04:08AM (#33716829)
Scheduling tasks on a system is done using UTC/local time which the system keeps accurate. Unix time is not used for that.
[ Parent | on HN ]
Re:Unix time is bad and needs replacement, not UTC by butlerm on Wednesday November 23, 2022 @07:10AM (#33718188)
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.

[ Parent | on HN ]