12

Background Information

I am developing an iOS application that is connected to a server, and requests can be made from the device towards the server to synchronize the local database with the server's database. Changes can occur on either one of the databases. The application also has an offline feature, where users can modify the data without being connected to an internet connection, and only going online in order to synchronize the device's local database with the server's database, by sending new data and receiving updates from the server.

Updated with more background information: The data handled is a form that must be completed in a certain amount of time. The time it is started is stored as a property on the model, and using said property, the application shows the user how much time left before this form is locked.

Problem

While the device is offline, the user can manipulate the time settings, which would make the data received from this device inaccurate.

I have searched for a way to detect changes to the device time settings but according to this SO answer, that does not seem to be possible unless my application is running in the background, which Apple is very strict about, and does not allow unless the application had one of the background modes enabled, which are not applicable in the application.

Updated with more information: As I mentioned in the updated part of the background information above, the data is forms that could have a time limit. Therefore a user can start a form on one device, but not finish it there. They would then synchronize the data to the server, jump to another device and complete the same form.

Proposed Solution

The closest I've come to solving this problem is to get the difference between the server time and the device time when the application is installed (It is sure to be online the first time the application is opened in order to configure it for this device), and using this difference as reference whenever I want to store a time-related value.

If the server detects a difference in the time, it will reject all data coming from this device, which will force the device to revert the data, update the time difference, and only then will data be accepted from this device.

The problem is that while the device is offline, the user could change the time settings, perform changes on the data, and then returning the time settings to what they were earlier before going online. The server would then detect no changes in time settings and will accept the invalid data.

Update to add another proposed solution: To elaborate more on my note in the questions below, and the comments with @Krypton, the uptime of the device does not help much in my situation because of the same problem as the above solution.

Taking the device's uptime and comparing it to the server time is perfect, until the user reboots the device. It is not manually changeable by the user, however all it takes it one reboot to break everything, which would yield the same inaccurate data for me. Fixing it would require calculating the new difference, which would not help when the device is offline.

Questions

  1. Is there an unchangeable timestamp that can be used as reference when saving a time-related value, such that it cannot be affected by changes to device time from the user? An example of this would be the time since the device was first activated. (Note: The closest I have come to finding anything related is the uptime of the device, but that doesn't help much in my situation)
  2. Is there a way any way to know the current time without the need to go online whenever a time-related value is going to be saved?
  3. Is there a way to fix my proposed solution, or any better solution?
Community
  • 1
  • 1
hannad
  • 822
  • 4
  • 18
  • 2
    a hint: elapsed time since device boot up is monotonically and constantly increasing. – Krypton Jan 06 '16 at 07:54
  • The way I've thought of using the elapsed time since device boot up was to find the difference between it and the server's current time. It may be unchangeable by the user, however if the user reboots the device, it would change, and I will be facing the same problem of my proposed solution, wouldn't I? – hannad Jan 06 '16 at 08:00
  • 2
    If the device is rebooted, the app needs to connect to the server to obtain the correct boot time again. – Krypton Jan 06 '16 at 08:03
  • Sometimes that is not possible, which is why I was looking for something that persists even through rebooting. – hannad Jan 06 '16 at 08:09
  • 2
    I'm afraid this is already the best we could do. AFAIK, there are only two things that you can use to keep track of time: the system clock, and the CPU clock (to measure things like uptime..). If you don't trust the system clock, then you can only rely on the CPU clock (which does not survive reboot) – Krypton Jan 06 '16 at 08:55
  • What's the point of having a timestamp? What we need here is a clock. – Krypton Jan 06 '16 at 09:16
  • Yes, I did not think that comment through and removed it before you replied. – hannad Jan 06 '16 at 09:23
  • How long is the available time for forms? Maybe it would be possible to not allow going to the background during them. – Belle Jan 06 '16 at 10:00
  • Duration is specified by whoever creates the form. It could be anywhere from 1 minute to a number of days. Also the duration could be open (infinite time). I also should have updated the question with what I commented on the other answer, but starting a form on one device and finishing it on another is not an uncommon situation. – hannad Jan 06 '16 at 10:02

3 Answers3

3

There are three ways to get the time on a device.

  1. NSDate. The time the user can modify.
  2. mach_absolute_time. This is the device's absolute time. But as you pointed out, this breaks everything on a device reboot. Also, this will get incorrect when the device is suspended.
  3. Boot time. The time since boot. Use uptime to get this.

You will want to use a combination of NSDate and uptime. Perhaps you could save the timestamp of both on any changes made to the form. You'll be able to calculate any difference between these values on changes and do the necessary calculations for your application. You may also want to save and compare with the server time if possible.

Now there is still the issue of a restarted device. If you were able fetch the time the device booted, you can calculate the difference between your last saved NSDate and boot time. Luckily, that is possible. See this answer or any of the other answers for possible ways to do so. Do note that implementing this could cause a small (1-10 seconds) inaccuracy.

Another option is not allowing the app to start without an internet connection after device reboot.

Also, the NSSystemClockDidChangeNotification should be able to help.

Edit: This how I would do this. Keep in mind, this is not perfect and whatever you choose, there will be trade-offs.

You can fetch the server time every so often when you have an internet connection and save this in the model. This allows you to calculate the time difference between the device time and your server's time. You can do this by saving the uptime and NSDate as timestamps in your model. If the device has not been reset, use uptime. Calculate the NSDate of boot (see here), and start measuring again. If these differences change significantly, you know the time's been tampered with. Keep in mind that these differences will change, even if the user does not change the time (measuring mistakes, daylight saving time...). What you consider significantly depends a lot on your application.

Then you have to decide what you want to do if the time has been changed. You can consider calculating if the time taken wasn't longer than the maximum (use uptime if the device hasn't been reset) or maybe discard the changes altogether.

Community
  • 1
  • 1
Belle
  • 273
  • 2
  • 15
  • Could you please explain a little more on how the combination could be used together? How would I handle if the time settings on the device changed? – hannad Jan 06 '16 at 11:34
  • 1
    What you do in that case is up to you. You can consider trying to calculate the actual time or rejecting the changes altogether. How you'd do this is dependant on your model and your exact goal. I will edit the question to explain how I would do this. – Belle Jan 06 '16 at 11:42
  • I'm going to give this some thought. It will be some time before I respond again with results. Thank you for the suggestion. – hannad Jan 06 '16 at 12:44
  • 2
    How do you even know if the device is rebooted? You need to fetch the device's boot time right? However device's boot time changed can be because of either a tampering attempt or a genuine reboot. Your solution still doesn't answer how to survive reboot. – Krypton Jan 07 '16 at 02:58
  • 2
    As explained in my 5th comment under the question, I believe the only solution is to refetch time from the server if boot time is found not to match with curtime - uptime. – Krypton Jan 07 '16 at 03:04
  • There are other questions that deal with how to find the device has been reboot. And you're right, you only know the time has been tampered with. Then you need the server. – Belle Jan 07 '16 at 06:55
0

You can never, ever rely on two devices having the same time. I would recommend that a server should use increasing time stamps, and if you got the data from the server with a server time stamp X, then all you should record with local changes is the knowledge that your changes are "some time after server time stamp X", without any accurate time. And independent on when your device thinks the change was made. If the server gave you information with a time stamp of today, 11:20:47.003692, and you make changes and the time on your device is 10:15:15:000000, then that change is not made at 10:15, but "after 11:20:47.003692 on the server".

gnasher729
  • 51,477
  • 5
  • 75
  • 98
  • I updated my question with some more background information which I thought might seem missing. As mentioned there, the data is actually forms that must be completed in a certain amount of time, and it is not uncommon for a user to start a form on one device and complete it on another. The above solution is indeed valid if I only needed to know when the change was made relevant to previous changes, however in my case, I'm afraid it has to be more accurate than that. – hannad Jan 06 '16 at 09:08
0

I had the same problem and your solution helped thanks. The thing you missed is that when the system clock changes or you reboot your device you can tell by how much it has been changed (how many seconds). All you need to do is adjust your stored time for the number of seconds the system clock has changed by.

Something like... if(iBootTime != iBootTimeBefore) dtMyTime.addTimeInterval(timeInterval:TimeInterval(iBootTime - iBootTimeBefore))

codefish
  • 51
  • 1
  • 6