If the two servers are NTP peers, use
ntpq -p
Which will show current offsets
Note that NTP takes into account network latency. If you know each server's offset from a common NTP server, that is about as accurate as you can get using standard tools.
UPDATE
I have two unix servers using NTP. Lets see what sort of time they are keeping:
$ sudo /usr/sbin/ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
hufu.ki.iif.hu 185.219.2.214 2 u 12 64 1 71.755 -0.073 0.001
web.puflet.info 188.138.107.156 3 u 11 64 1 78.248 0.417 0.001
84.2.44.19 10.20.75.140 2 u 10 64 1 74.721 -1.076 0.001
$ sudo /usr/sbin/ntpq -p otherbox
remote refid st t when poll reach delay offset jitter
==============================================================================
+ntp2.exa-networ 195.66.241.10 2 u 799 1024 377 43.405 7.796 218.471
+mantaray.netine 249.240.53.144 3 u 289 1024 377 34.782 8.484 212.631
*rilynn.me.uk 81.2.117.228 2 u 765 1024 377 45.665 6.804 142.023
+ntp.thirdlight. 193.67.79.202 2 u 791 1024 377 38.322 9.871 223.397
They are using different servers because they use servers from the ntp pool.
I'll temporarily add otherbox to this server's config so I can directly measure the time offset
$ sudo vi /etc/ntp.conf
(added `server otherbox`)
$ sudo /sbin/service ntpd restart
$ sudo /usr/sbin/ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
gamma.h3x.no 78.70.33.22 3 u 4 64 1 34.840 -0.964 0.001
web.puflet.info 188.138.107.156 3 u 3 64 1 78.148 -1.243 0.001
alpha.rueckgr.a 129.69.1.153 2 u 2 64 1 61.495 -2.362 0.001
otherbox.exampl 60.155.73.34 3 u 1 64 1 0.604 -11.286 0.001
It looks like timestamps on my two servers are about 11 ms different.
The Linux kernel has had an xstat(2) system call in the works for several years, now. David Howells of RedHat did much of the work. xstat(2) allows one to retrieve the creation time (sometimes rechristened the "born time" or "birth time" in the Linux and BSD worlds for no really good reason) of files from the several filesystems that support it, including EXT4 (which has a creation timestamp on disc) and CIFS (which with its DOS/OS/2/Windows heritage has supported a creation timestamp as a first class citizen for decades). M. Howells worked on the CIFS patches that go along with the system call.
OpenSolaris and the BSDs actually do have a st_birthtim datum in their stat(2) system call right now, and the feature is accessible to script writers via application programs such as find and ls. On the OpenSolaris ls man page you'll find crtime alongside atime, mtime, and ctime in several places. Similarly, the FreeBSD find command has -Bmin, -Bnewer, and -Btime primaries. And the Mac OS ls has a -U option.
If you were writing your script for OpenSolaris, the BSDs, or Mac OS 10, you could just get on with whatever you want to do with creation times right now. Indeed if you were writing for Windows you could do the same. Cygwin has supported st_birthtim since 2007, making Win32's CreationTime timestamp, which it has had since the first version of Windows NT and which Windows NT maintains on both NTFS and FAT volumes, available to Cygwin tools.
However, the same isn't true in the GNU Linux world. Creation time capability has yet to make it to GNU coreutils' ls or to GNU findutils' find. Indeed, it isn't even part of the mainstream Linux kernel yet. Part of the problem is that the xstat(2) system call got bogged down in a diversion where people wanted to keep three timestamps, instead of have four as in the Windows NT kernel API, and dump ctime to replace it with crtime.
Linus Torvalds' response in 2010 was that "it's all totally useless and people can't even
agree on a name" and "Let's wait five years".
In fact, as I suspect most people reading this will know, the world has been widely agreeing the name "creation time" since the 1980s and we've been waiting at least 25 years already. It's the name used in OS/2 1.0; it's the name used in VMS ODS-1; it's the name used in Windows NT 3.5; it's the name used in SMB; and it's the name used in the question. ☺
Further reading
Best Answer
I think this article has an answer to your question: Notify userspace about time changes. But please note that the patch mentioned in the article is quite recent, so you have to check your linux kenel vesrion first.
If your kernel does not support userspace notification mechanism, then you can implement the following algorithm (in pseudocode):
Hope this helps.