SysTimeSet()/..Get() and RTC backup UNIX time offset?

[me9atherion]

Hi.
I am working on porting LoRaMac node stack implementation to another platform (not supported by demo projects).
I need to build LoRaMac node at the top of some allready implemented runtime code for timing, GPIOs and so on.

Currently I am working on timing and frustrated by one thing in systime.c/h:

Why does subtraction or addition is done towards to UNIX time offset value which is stored in RTC backup registers in SysTimeToMs()/SysTimeFromMs()? The usage of RTC backup value is clear for setting "absolute" system time in UNIX format (SysTimeSet()/SysTimeGet()) - we have RTC counter which is never stopped and setting new system time value is just calculation and storing of offset to current RTC counter value to represent UNIX time correctly by addition in future call to getter.
But is there some special reason to do similar math with offset value for SysTimeToMs()/SysTimeFromMs(). As I see these functions called from stack to keep tracking of some "relative" delays (towards to previous timestamps). What if system time will be changed between calls to SysTimeToMs()/SysTimeFromMs()?

[mluis1]

We have implemented this quite some time ago and I don't really remember the reasons behind the choices we have made.

Thinking on the subject again please find below my understanding.

The SysTimeToMs and SysTimeFromMs are being used to convert RTC counter values to/from SysTime_t this is the reason why the backup offset value needs to be used in the conversion functions.

Concerning the "system time" change I think that there is no issue as SysTimeToMs and SysTimeFromMs functions are only called locally in order to convert from one timing system to the other. Which means that no time change can happen while executing the local process .

The only way I see where things could go wrong concerns the Class B implementation in case one tries to change time to a wrong value. By doing so the end-device will compute the beacon and ping slots reception windows opening at the wrong time. (This will be true whatever conversion implementation we have.)
Although, the stack can recover from such situation because after a certain period of time not receiving beacons the stack will revert its operation to Class A. Then it is up to the end-device application to synchronize its time and switch to Class B again.

If you have a better way to handle this please feel free to propose a pull-request.