Network time issue: AT+CCLK reports invalid datetime "80/01/06"

Hi,

We have found an odd issue related to modem RTC timekeeping while using the nrf date_time library. It seems that the modem is setting its RTC to an invalid time. The issue only occurs in certain locations, although we can reproduce it faithfully:

  1. A power-on reset is applied to the device.
  2. The modem RTC reported by AT+CCLK is "15/02/01,00:00:00". (I assume this is a default time set whenever a POR is applied.)
  3. Modem registers to mobile network.
  4. Applications receives a valid %XTIME notification from the modem that translates into the correct current datetime (e.g. "62108010543040", which would translate to 2026-01-08,01:45:03). This time is initially applied by the date_time library for system time, as expected.
  5. If we then query the modem RTC with AT+CCLK, the result is NOT a valid time, but instead something around "80/01/06,00:20:00+36". This time is always (nearly) the same after we first register to a network and receive an %XTIME notification (i.e. it does not change day to day or even hour to hour).
  6. Eventually, when CONFIG_DATE_TIME_UPDATE_INTERVAL_SECONDS expires, the date_time library then queries the modem RTC with AT+CCLK, receives an invalid time based on the above, and applies it for system time.

Some more details regarding our environment:

  • We are able to reproduce the issue only in certain locations. We have a test device we are using to debug the issue remotely via test firmware and remote logging. It seems other devices in different locations/networks may also be experiencing the same issue, but we have not been able to confirm this 100%.
  • Unfortunately we do not have the capability to capture a modem trace on the affected test device.
  • So far we have only seen the issue on NB-IoT networks, although we have not tested to see if we can reproduce the issue with LTE-M. We plan on attempting that.
  • We are using an nrf9160 with mfw 1.3.5 and nrf-sdk 2.4.3.

We have our own workaround to prevent the date_time library from applying the invalid time provided by AT+CCLK, but we wanted to bring the issue to your attention as we are not sure what the root cause actually is. We assume it is either a faulty network time message provided by the operator, or a fault in the modem interpretation of the network time message, but it is impossible for us to know given our limited visibility.

Does your team have any experience with this kind of issue occurring? Do you have any explanation for why the %XTIME notification time is valid even though the modem RTC time is invalid?

Do you have any suggestions on how we could best bring the matter forward with Nordic or with network operators? Without a modem trace, it is of course difficult to prove whether the fault is in the network time message provided by the operator or the modem itself.

Thank you for your help!

  • Hi,

    I unfortunately wasn't able to reproduce your issue.

    Can you maybe share the full logs of the AT command you sent ? Or some code snippets to see in a bit more details what you are telling the modem to do ?

    We are using an nrf9160 with mfw 1.3.5 and nrf-sdk 2.4.3.

    Do you know it that still happens with newer SDK and modem firmware version ?

    Unfortunately we do not have the capability to capture a modem trace on the affected test device.

    You said you can't capture modem traces. I don't know your hardware setup, but can't you maybe do it through RTT ?

    Does your team have any experience with this kind of issue occurring?

    Not that I have heard of...

    Do you have any explanation for why the %XTIME notification time is valid even though the modem RTC time is invalid?

    Did you, by any chance, deactivate AT%XNETTIME ? It should be activated by default, but you can check its state with the command "AT%XNETTIME?".

    Do you have any suggestions on how we could best bring the matter forward with Nordic or with network operators? Without a modem trace, it is of course difficult to prove whether the fault is in the network time message provided by the operator or the modem itself.

    If you have a spare DK, you can build try to reproduce the bug on this device with AT commands, and then you should be able to get the modem traces you need to prove that you receive wrong information (if it is the case).

    Other than that, you may also simply ask the operator to check if they can see something abnormal on their end.

    Best regards,

    Simon D-M

Related