The problem is not really with leap seconds themselves but that they are virtually universally implemented in computer systems as part of the "seconds-since-epo

The problem is not really with leap seconds themselves but that they are virtually universally implemented in computer systems as part of the "seconds-since-epoch time" as the lowest level interface to the clock (e.g. POSIX clock_gettime). This is apparently nice because then you can convert this to a calendar date without considering leap seconds (assuming the Gregorian calendar). But for anything that actually needs accurate timekeeping (time keeping in natural terms not calendar time) this is a disaster because the time will jump by a full second, and if it jumped backward, this will also result in ambiguous times. So with leap seconds inserted into your clock, your clock may as well be worthless: it does not unambiguously define time, and you cannot subtract values to get durations. Note that the current approach is not fully correct even when you care about calendar dates, because in case of a positive leap second, your clock will never show the :60 second tick but repeat :59 twice (due to ambiguity). By the way, it is easy to convert a leap-second-uncorrected seconds-since-epoch value to a leap-second-corrected one (for compatibility with SW that assumes this). I think this will do it: T_corrected = T - N_positive(T) + N_negative(T) where N_positive is the number of positive leap seconds up to time T, and N_negative is the number of negative ones. (yes, positive ones are subtracted and negative are added - I hope I didn't mess that up) Summary: leap seconds are not wrong per se, but they are implemented in a very stupid manner in common operating systems - the time values the OS gives allow neither correct conversion to calendar time nor calculation of relative times.