Understanding specification v1.0.3 and v1.0.4 at DeviceTimeAns MAC command

I read documents “LoRaWAN® L2 1.0.4 Specification” and “LoRaWAN 1.0.3 Specification” and not sure about correct understanding one simple moment at section ““5.9 End-Device Time Commands (DeviceTimeReq, DeviceTimeAns)””:
Is end node must add leap seconds for convert received GPS time from DeviceTimeAns MAC command data to UTC or network server must add leap seconds to DeviceTimeAns payload?

Upd. I see two versions of implementation:

  1. Network server send in DeviceTimeAns “original” GPS time without adding leap seconds. End node add to extracted from DeviceTimeAns GPS time leap seconds and get correct UTC time.
  2. Network server send in DeviceTimeAns GPS time with added leap seconds. End node apply received time to convert to UTC without leap seconds.

In both cases correct UTC time can be correctly applied at end node side. What version of implementation is correct and conforms to specification?

In the 1.0.3 version of the spec it says

To convert this field to UTC time, the leap seconds must be taken into account."

Since the “field” is what is present transmitted in the MAC command response, at least for that version of the spec the subtraction would have to be done on the receiving end.

Since the difference is on the order of 18 seconds you could probably confirm this by setting a node time display (serial log output?) and manually comparing it to something with remotely decent NTP time.

As for why, there’s also a hint in the spec that a primary purpose is [perhaps not for making LoRaWAN referenced desk clocks but] for acquisition of class B beacons, and GPS timed LoRaWAN transmissions use the GPS epoch time, rather than UTC time (in the classic packet forwarder protocol, the “tmms” field rather than the “time” field)

To expand on the concept of desk clocks, using the actual time to send uplinks is a recipe of disaster if you end up with a pile of nodes all transmitting at the same time. It’s also contrary to the best practises of adding some randomness / jitter in to the uplink schedule to ensure that devices can’t be in sync with each other.

The only time I’ve finagled a time update was for a device that was capturing a very small data point infrequently so it had an RTC to wake the device, it stored the captures in memory and then sent a bunch of them all in one go with an indicator for the start time. Works OK, usually off by a fraction of a second as it got really silly trying to account for all the little delays in the response - either own downlink or a MAC request. There is a good discussion on one of the PaxCounter threads on how to eliminate the delays.