I think I found a small bug in date_time.c

[Burt]

Am I correct?

burt@P51:~/ncs/v3.1.1/nrf/lib/date_time$ git diff .
diff --git a/lib/date_time/date_time.c b/lib/date_time/date_time.c
index 495b2a6123..f6267e299a 100644
--- a/lib/date_time/date_time.c
+++ b/lib/date_time/date_time.c
@@ -132,7 +132,7 @@ int date_time_now_local(int64_t *local_time_ms)
                LOG_ERR("The passed in pointer cannot be NULL");
                return -EINVAL;
        }
-       if (!date_time_is_valid()) {
+       if (!date_time_is_valid_local()) {
                LOG_WRN("Valid time not currently available");
                return -ENODATA;
        }

Burt

[tesc]

Hi,

Thanks for reaching out to us, it is highly appreciated!

I do agree it looks a bit suspicious, yes.

Looking at the code, the difference doesn't seem that large in practice (it only seems to affect what error codes are returned in some situations,) but we will look into it anyway to see if it should be changed.

Thanks again for reporting!

Regards,
Terje

[Burt]

Thanks, Terje. I am guessing that the only reason I decided there was something wrong is that date_time_is_valid_local() was not being used, and along with symmetry would lead one to believe it was intended for date_time_now_local(). On the other hand, being that it is not a static function, it could be intended to be used outside of the library.

Burt

[tesc]

Hi,

Yes, it could be both ways. It may make sense to check if time info exists at all (which is what the current implementation does). Regardless, the code is functionally correct in the success case, and a code change only affects error return values. I would expect low priority for looking into it, but at least we have registered that it may need looking into.

Regards,
Terje

[Burt]

Thanks, Terje. I will close the ticket.

Burt