Remote command result includes only a rough approximation of the timestamp |
||
Issue descriptionAs a background, the result of remote commands execution is transmitted back to DMServer through the RemoteCommandResult proto. This proto includes a timestamp field, which seems to be interpreted by the server and used, e.g., for rendering at cPanel. What is the expected result? The RemoteCommandResult.timestamp field is the number of milliseconds since Epoch in UTC timezone till the time at which command was executed (as documented in the proto at [1]). What happens instead? The RemoteCommandResult.timestamp field is calculated using base::TimeTicks ([2]), which has some quirks like the possibility of standing still while the device is asleep ([3]). As the fake TimeTicks that approximates Epoch is not moving either, the resulting timestamp may become increasingly wrong during a single session. Actually, base::TimeTicks is even documented as "can not be converted to a human-readable time". [1] https://cs.chromium.org/chromium/src/components/policy/proto/device_management_backend.proto?l=1102 [2] https://cs.chromium.org/chromium/src/components/policy/core/common/remote_commands/remote_commands_service.cc?l=128 [3] https://cs.chromium.org/chromium/src/base/time/time.h?l=19
,
Apr 27 2017
Yes, or just base::Time::ToJavaTime() (which we recently started using across our policy code - 35629b9c2d21ae7af4ec8ebdcec1c2c21a042880). I'm curious whether there was any specific reason to use TimeTicks in the remote_commands code. (It could be beneficial for measuring task durations more accurately, but this doesn't seem to be used there.) Otherwise, I'm fine with fixing this once I get some spare cycles. |
||
►
Sign in to add a comment |
||
Comment 1 by atwilson@chromium.org
, Apr 25 2017