Comment 2 for bug 1321775

I'm not sure that I understand this report as it pertains to indicator-datetime.

I'll rerun the steps above to see if I can reproduce and address the high CPU load in indicator-datetime. However this seems like a red herring to me for the problem described in the summary:

(1) indicator-datetime and qt5organizer-eds both run their unit tests in isolated EDS sandboxes so that they can always guarantee that its EDS data is always the same when the tests are run. Do the calendar and clock apps not also do this?

(2) I don't see how it follows that high CPU load from a 3rd party app that only reads from EDS, never writes, will cause another app's tests to fail. nik90, you can try removing indicator-datetime from the equation by running "stop indicator datetime" from a shell before running the steps you outlined in the bug description.