How reliable is uptime?

delta1 = (read_reliable_remote_clock() - read_uptime())
sleep some-time
delta2 = read_reliable_remote_clock() - read_uptime()

will 'delta1' and 'delta2' going to be within a reasonable value of eachother?
'reasonable'  here is < 2 seconds.

in 'sleep some-time', assume anything can happen such as setting of system clock or a sleep of 24 hours.  do not assume that the hardware clock on the system is terribly reliable.

== Background ==
maas often has to boot systems with a bad hardware clock.  Either 
the hardware clock simply has no battery (and has to be set every boot)
or some other reason (http://pad.lv/1499869).

cloud-init runs on those systems early in boot, and tries to authenticate
to the maas datasource via oauth.  oauth contains a timestamp in the request
so cloud-init ends up making a request with timestamp from the system clock
and maas oauth backend refuses, and returns 403. (http://pad.lv/978127)

the quick summary of the fix is that when cloud-init sees a 403 on oauth,
it will read the timestamp in the response header and try again with that,
instead of the time from the local system.  If that request was then
successfull, cloud-init would store the offset of its clock and modify
future requests with that offset.

That works reasonably well, until something fixes the clock after cloud-init
has established an offset.
Ie:
  cloud-init oauth try and fail 403
  cloud-init update offset
  cloud-init try again, and succeeded, stores offset
  <something updates clock>
  cloud-init do anotehr request, fails as offset is no invalid.

that 'something' can be anything, but here is systemd's network time service.

One possible solution here is to not store the delta of the current system clock and the "right" time, but to instead store the delta between kernel's uptime and the "right time".  By doing that, even if the clock changes the uptime will only move forward and we should be able to continue to get a resonable time amidst time changes to the local clock.