Issue with updating time programatically

[cirrusio]

That is pretty much it... however, the time rests to 1970, not 1904 (don't understand why) and the system takes 1.5-2 minutes to respond to network requests. Besides the annoying user experience, the big problem odds that I am using shared variables to communicate and handle some of the configuration state, do this means that until the network comes back up, the system can not move forward. I feel like i am being burned for a design decision that has been a common choice for made up until now. Why would it be reasonable to assume the system would go down for so long? Could i have something configured incorrectly? I have another sbRIO here so i may see if I can replicate this behavior.

[cirrusio]

That is pretty much it... however, the time rests to 1970, not 1904 (don't understand why) and the system takes 1.5-2 minutes to respond to network requests. Besides the annoying user experience, the big problem odds that I am using shared variables to communicate and handle some of the configuration state, do this means that until the network comes back up, the system can not move forward. I feel like i am being burned for a design decision that has been a common choice for made up until now. Why would it be reasonable to assume the system would go down for so long? Could i have something configured incorrectly? I have another sbRIO here so i may see if I can replicate this behavior.

[cirrusio]

Oops... forgot to answer your question - it does ultimately come back, it just takes a long time.

[cirrusio]

Still not sure why this happens, but I ended up replacing the battery and now I have no major issues with time as the system maintains the time as necessary.  Would still like to hear why this is happening.  I suspect there is a lot that relies on the time stamp and therefore all of that needs to adjust.  I am just not sure why the period of adjustment seems to be dependent on the difference in the current time stamp and the new time stamp.