Not all the mobile operators support automatic time synchronization mechanism called Network Identity and Time Zone (NITZ), therefore this setting may have no effect at all. Even if your provider supports NITZ, the information it sends may be inaccurate. There are also devices without SIM card, especially tablets that have no access to the network time. If Android Automatic mode works fine for you, then you are lucky and probably don't need ClockSync, otherwise it's recommended to disable it to avoid conflicts and getting incorrect time, see also a question about wrong time after synchronization below.
NTP protocol used by ClockSync to get the data from the time servers works via UDP, connection is made to port 123. You router, local or corporate firewall, proxy server, or Internet provider may be blocking access to the public NTP servers. There is not much ClockSync can do about it, but you can try some other WiFi network or switch to the cell data, or vice versa. If there is a local NTP server available in your network, try to use it instead.
I have plans to support other ways to get time if NTP is blocked in your environment, it includes GPS time and getting time from the HTTP response header of the public servers (less precise than NTP, but still better than nothing).
Android system doesn't allow third-party applications to change system time. It's OS security restriction and the only way to overcome it is using root (run commands via su with administrator permissions). You need rooted ROM for this feature to work, su binary file and Superuser Permissions application. These are normally included with ROMs from such vendors as Cyanogen or MoDaCo. If you don't know how to root your device, please refer to How To Root Your Android Phone / Device for the detailed instructions. Note that since version 1.1.2 you can enable Rootless Mode and sync manually, see below.
It makes ClockSync useful on devices without root. When this mode is enabled, instead of performing automatic synchronization ClockSync will retrieve the atomic time and compare it to the system time. If the difference is greater than configured threshold (60 seconds by default), you will get a notification that your clock is off time. Tap on the notification or perform synchronization from the ClockSync interface to start the assistant. ClockSync will open system Date & Time settings dialog and will also show a hint at the bottom of the screen with the time and date you should set to get perfect synchronization. Follow the instructions and adjust the values according to the hint. Once offset becomes lower than 30 seconds, the assistant will stop. You can also stop it manually by tapping on the ongoing notification.
In the worst case precision would be ~30 seconds if Android doesn't allow to set or reset seconds. Why not 60 seconds? If the seconds part difference is in 30-60 range, a minute can be added to make it 60-offset and ClockSync knows how to do it. For example, consider system clock time 01:00:00 and atomic time 01:00:40 (offset = -40 seconds). Instead of asking you to set 01:00 values (and actually get the same 01:00:00 time, since seconds can't be changed), ClockSync will ask you to set time to 01:01. The new time is now 01:01:00 (well, maybe :05 or :10 seconds since you need some time for correction, but it can be ignored because atomic clock will add the same amount of seconds), offset becomes +20 seconds which is better than -40 in most cases. This mode would be very useful if your phone doesn't sync via NITZ, has heavy time drift and can't be rooted for any reason. It will also help if some towers provide wrong time (you may need more frequent automatic updates configured in ClockSync, like every hour).
Some devices (mostly Samsung and some HTC) reset seconds when you set time manually. Starting from version 1.1.5 ClockSync has a special setting "Device resets seconds". If this option is enabled, assisted mode asks you to manually set time one minute ahead of current correct time and displays countdown until seconds become zero, so that when you press Set button, you will get exactly the precise time synchronization (depending only on your reaction speed). To further assist in this task ClockSync will start to play Greenwich Time Signal 5 seconds before you need to press Set. GTS is 5 short beeps and one long beep. You need to press Set after the 5th short beep, on the very start of the 6th long beep that indicates the start of the next minute.
When in rootless mode, Automatic synchronization (which works as automatic time verification) and notification options should be enabled to get maximum from ClockSync.
ClockSync uses System.setCurrentTimeMillis() call to set system time. It works only after permissions for /dev/alarm are changed. This method returns "false" in case of an error. Normally it happens only if it was not possible to change time (like when KNOX/SELinux is enabled on Samsung devices or recent Android versions). In this case ClockSync falls back to the alternative time setting method: "date" command line utility. On some devices setCurrentTimeMillis returns "false" even after setting time successfully. It would be no problem if "date" command worked fine, however there are devices where this command accepts arguments in some non-standard format which leads to incorrect time after synchronization.
These two bugs together cause ClockSync to set incorrect time and ask you to contact me for help. Enable this option if it happens on your device. ClockSync will ignore setCurrentTimeMillis result and will not fall back to "date" command for setting time. It will not help if "date" command is the only way to set time on your device, but is not compatible with the standard format of the arguments. Please contact me for help if it happens for you.
Starting automatically is necessary to initialize system timers so that automatic synchronization can work. If you don't have automatic synchronization enabled, ClockSync will do nothing on boot and finish instantly. The system will free resources when needed, you should not worry about it. Since ClockSync 1.1.3 this feature is used only when you have enabled synchronization on boot, while timers are set and cancelled depending on your network connection state. From version 1.1.6 time zone transition timer is set on boot if you have "offline database" option enabled and selected time zone has transitions to DST and back.
Most likely your system time zone setting is not correct. If you are using Automatic setting, disable it and set time zone manually in Date & time settings. Disabling the Automatic setting will also help you to avoid device clock syncing to possibly incorrect cell network time and then back to NTP time by ClockSync. You can also try the Detect time zone option. It's based on the public web service (which may be down at certain time intervals) and will find out your time zone from the geographic coordinates. Note that reverse geocoding is a complex task and may yield incorrect results in some corner cases, so use with care.
In some cases time zone information in your Android ROM may be incorrect. Even when you select the correct time zone in Android settings, you may still get the wrong offset reported for this time zone by the OS. In such case you have to choose another time zone which yields correct time on your device.
Since version 1.1.4 ClockSync provides advanced time zone settings. You have a choice between GeoNames and Yahoo! PlaceFinder web services that provide time zone based on location. There is also an option to use time zone offset information from the offline database to show correct time in case system time zone data is out of date (like the recent daylight saving cancellation in Russia lead to all Android devices showing incorrect time). Many users blamed ClockSync and put low ratings in Market, while the problem is actually with the phone vendors not providing timely updates for the system time zone database. You can also override system setting with UTC (GMT+0) time zone and specify custom offset (choosing from all possible valid values) or set up time zone manually from the list provided by the offline database.
I want to clarify it again, NTP servers do not provide time zone, they provide only UTC (GMT) time, therefore it is critical to have correct time zone set on the device. However, correct time zone ID is not enough, your system must also return correct offset in hours for the time zone which may be not possible if system time zone data (zoneinfo) is not up to date. Without correct zoneinfo and time zone setting ClockSync can display wrong time for both atomic clock and system clock, it's normal and must be fixed using one of the provided ways by you. This data is stored under /system/usr/share/zoneinfo directory and can be updated only if you have root and write permissions (requires S-OFF on HTC devices). It's also risky as it can damage your system permanently. Normally your phone vendor should release regular updates to this data, but they usually don't care. If you absolutely need to update zoneinfo, you can install TimeZone Fixer application which is known to work well on most rooted devices. ClockSync provides a shortcut to install/run this app from the settings. Please note that I'm not the author of TimeZone Fixer, it's maintained by forceg, feel free to contact him with any questions (check the app Market page for details).
So, if you get wrong time (atomic, or system or both), you have the following options to fix it:
NOTE: when using time zone with nonzero minutes offset (from database or overriding system setting), it cannot be mapped to POSIX Etc/* time zone, it will cause some applications that rely on android.text.format.Time to show time in UTC instead of user set time zone (one of the examples would be system analog clock widget). At the moment there is no way to correctly override system time zone when offsets minutes part is nonzero.
The Network Time Protocol (NTP) is a protocol for synchronizing the clocks of computer systems over packet-switched, variable-latency data networks. NTP uses UDP on port 123 as its transport layer. NTP is one of the oldest Internet protocols still in use (since before 1985). ClockSync uses public NTP servers for time synchronization, Internet connection is required for this feature to work.
While it's possible to use GPS to get time, it's not practical on Android for multiple reasons. Most important is that Android system doesn't support PPS (pulse-per-second) which is required for perfect time synchronization from the GPS device, this would make time synchronization accurate only up to 300ms while NTP gives you 1-10ms precision. The second reason is that GPS requires some time to start up, open sky and eats your battery. This makes automatic synchronization not very usable for most people as we usually don't have GPS signal in our flats/houses/offices. I do plan to add manual GPS synchronization for emergency cases like no Internet coverage or when roaming. At the moment there are several bugs in the majority of Android versions which will make this feature unusable. Until Google fixes these issues, this feature would work only on a limited number of Android devices. At the moment you can use GPS Time application.
In order to set time, ClockSync changes the alarm device permissions to make it writable for all users. Then it sets the time and finally it restores permission so that other apps can't do any harm without your permission (though, it's very unlikely). This actually requires 3 calls to the shell process with the superuser permissions. First one to verify that su is available on device (the result is cached until app restart), the second call to make alarm writable by all users and the third call to restore the original file permission. Every su call on Android starts Superuser application which verifies the permission of the application to use su, optionally displays requests and notifications. Superuser application calls are expensive because each time the new JVM is started and extra ~10-20Mb of memory are consumed. If you keep this option disabled, ClockSync will run su only once, when you sync for the first time leaving the alarm device writable. When syncing next time, if the file is writable, su is not called at all making synchronization almost instant and saving your CPU/RAM/battery. Paranoids who think that some other app can possibly use it to change time without permission should enable this option.
First of all make sure that Background Data option is enabled, ClockSync obeys this system setting and will not try to use data connection if it's disabled. If you use "Only on Wi-Fi option", your device may turn off Wi-Fi when sleeping and ClockSync will not sync. Try disabling this option or configure your Wi-Fi sleep policy to Never. Some Android devices have problems with timers and when you turn on "Only when awake" option, timer may be never triggered by the system, it's pure Android bug, so either update to the new ROM or disable this option. Use History in ClockSync Settings to find out when the last synchronization attempt has been made and why it failed.
15/30 minutes, 1/12 hours and 1 day intervals (marked with *) can be used for inexact repeating mode to save battery. Android documentation says:
"... repeating alarm that has inexact trigger time requirements; for example, an alarm that repeats every hour, but not necessarily at the top of every hour. These alarms are more power-efficient than the strict recurrences, since the system can adjust alarms' phase to cause them to fire simultaneously, avoiding waking the device from sleep more than necessary. Your alarm's first trigger will not be before the requested time, but it might not occur for almost a full interval after that time. In addition, while the overall period of the repeating alarm will be as requested, the time between any two successive firings of the alarm may vary" .
While it's practical for short intervals like 15, 30 or 60 minutes, it may become a problem if you want to use much longer interval like 1 day (24 hours). In such case synchronization may not occur exactly every day, but may happen in about 2 days since the last sync. Enabling Strict interval option allows you to use exact repeat intervals for more predictable synchronization, especially when you don't want to sync too often.
Better precision is achieved using two techniques. First one is to query NTP server 5 times with 1 second delay between queries and then use the average offset of these 5 requests. Network conditions change over time and average is always better than one single request to a server. The second trick is to actually wake the device. While querying the server ClockSync acquires wake lock so that Android system doesn't kill the process in the middle of its work (standard practice for background operations). However, normal wake lock doesn't fully wake the device which in fact leads to higher network latency because CPU, Wi-Fi or mobile network modules still remain in power save mode. Higher network latency leads to less offset precision from the NTP server. When you enable High precision mode ClockSync uses full wake lock mode, network latency becomes lower and NTP offset precision becomes higher.
Be aware of the side effect! To perform full wake, application must turn the screen on (at least in dimmed mode). You can notice that your device screen turns on in dimmed mode (still locked) for a short period of 5-10 seconds and then turns off again after ClockSync completes the synchronization in high precision mode. It may be annoying if you are syncing often, so use this option wisely. If you are interested in technical details, please refer to the corresponding Android documentation section. I am not completely sure what exactly causes such behavior, but I have verified it myself on several different Android devices, with screen turned on NTP round trip would be 50ms, with turned off it becomes 100ms (just an example). Depending on the device model, NTP server, network type and conditions this mode may give you ~300ms better precision when synchronizing time in background. It also explains why you can observe severe offset difference just after background sync when not using this option (time is synchronized with lower precision, offset becomes high, time is adjusted, then you open ClockSync, device wakes up, offset is updated with better precision and you notice your clock is not in perfect sync again). Enabling this option helps to avoid such situations. For even more consistent results it's recommended to use fixed IP address for your best nearby NTP server instead of the default pool.ntp.org which may return servers with varying latency and time precision.