How does Unix Epoch time behave on a leap smeared clock?

Consider a machine whose time is smeared during a leap second with a noon-to-noon linear smear.

I'm wondering how the system clock provides accurate Epoch time during the smear period.

Example:

• The leap second is scheduled at 31st dec of 2016.

• On the machine, a Unix timestamp at 11:59:00 on 31st of December is 1483185540

• At noon the smearing starts, which means the local clock of the system at 1:30 pm is already a few microseconds behind TAI and UTC. The Epoch timestamp should be 1483191000 (exactly 1 hour 31 minutes later), which is not accurate to TAI/UTC anymore since Epoch doesn't respect leap seconds
• At 12pm UTC adds an extra second: 11:59:60 pm, the local smeared clock should continue normally
• Till, at noon 1st of January global UTC and local UTC sync up again, the local Epoch clock is now an entire second behind global Epoch/TAI

How is this inaccuracy resolved? Does the local Epoch time skip a second once the system knows a leap second happened? Or how is this issue handled?
Does it depend on the implementation of the clock used to calculate the time? If so, how does GNU's coreutils date handle this?

The inaccuracy is not resolved. The Unix Time remains a count of seconds since 1970-01-01 00:00:00 UTC excluding the inserted leap seconds. This has the benefit of making the count of seconds easy to convert to {year, month, day, hour, minute, second} form.

It has the problem that the subtraction of two Unix Time time points that straddle a leap second insertion will result in a time duration that is one second less than reality.