Question

So I am writing the program in xcode that syncs with a database on a different server, but the information to update is dependent on the date last synced. What is the best way to save a “dateLastSynced” timestamp so that when I open the program it can automatically sync the changes that happened after the datestamp?

Answer 1

Clearly [NSDate date] gets you the current date in NSDate format, but if you’re logging it in a SQLite database, you could also use the appropriate SQLite date and time function, for example SELECT datetime();.

But, if you’re using this timestamp as a parameter you use in your remote web service requests (i.e. a timestamp that the server is going to check against it’s own internal clock and timestamped records), I’d suggest you do not use your local clock at all. Determine the dateLastSynced from the timestamps you received from that server and not use your local clock at all. Effectively, you let your web server’s timestamp mechanisms govern the process. Thus, you’d grab the appropriate timestamp field from the remote server and store that in your database’s dateLastSynced timestamp. The key is, you don’t want a minor misadjustment of clocks (or worse, sloppy time zone management) to adversely affect your syncing logic.

Personally, when I’m coordinating the sync between a remote database and my local database, I generally have a one-row table in my local database for configuration information, and I store this server-based timestamp there. You certainly could use NSUserDefaults (see Preferences and Settings Programming Guide) or a plist or whatever, but I personally view this sync timestamp as a property of the state of my local database, so I therefore I feel more comfortable keeping it there. If you keep it elsewhere, do so with some consideration of other processes that could update your database (e.g. what’s your migration plan when the user updates their app to version 2.0 with a new/modified data structure).

So, for what it’s worth, I personally would keep database synchronization information in the database itself, even if it feels silly to have that one row configuration table. (As an aside, I also tend to include fields like app/database version numbers in my configuration table, too.)