pfSense

Difference between timestamps is -9764. Assuming that's seconds, nearly 3 hours. Is it possible that NTP has come up and set the clock back?

rc.bootup says (in part):
[...]
system_ntp_configure(false);
mwexec_bg("/usr/local/sbin/ntpdate_sync_once.sh", true);
echo "done.\n";
[...]
/* lock down console if necessary */
reload_ttys();

/* load graphing functions */
enable_rrd_graphing();

/* enable watchdog if supported */
enable_watchdog();
[...]

Where /usr/local/sbin/ntpdate_sync_once.sh loops up to 3 times attempting to get non-zero status out of:
/usr/local/sbin/ntpdate -s -t 5 ${SERVER}

Since the ntpd default is to slew the clock, unless the offset is greater than +- 128ms, in which case the clock is stepped using settimeofday(),
it could be that RRD is starting in the middle of a large offset, brought on by ntpd running, or even (I've not thought this through), that the offset so large (backwards), that it's before the previous invocation of RRD stopped recording.

See: http://doc.ntp.org/4.1.1/ntpdate.htm

Note that this file recommends the use of '-b' switch for ntpdate in startup scripts, which always steps the clock. (We don't do this.)

Note as well that ntpdate is deprecated: http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate

The new shiny is 'ntpd -g' "allow the first adjustment to be Big", and, in fact, ntpdate can be all but replaced with:'
ntpd -gqc /dev/null server1.name.net server2.name.org server3.name.com

But, really, the whole mwexec_bg("/usr/local/sbin/ntpdate_sync_once.sh", true); crap should be eliminated, we already run:

/usr/local/sbin/ntpd -g -c /var/etc/ntpd.conf -p /var/run/ntpd.pid

Which should be good enough, except for the initial offset problem.

At a minimum, we should probably change the usage of ntpdate to be:

sntp -sS ${SERVER}

Note that '-t 5' is implied here.

But, at the end of the day, It is no longer necessary to set the time before starting ntpd. Using the -g option to ntpd means the system will need to have the time set to within 68 years (more or less) before starting ntpd.

See: http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate#Set_the_time_before_running_ntpd

updated subject to issue that was fixed here.

OP's issue is the time was 3 hours into the future at some point, and after correcting via NTP, there was a period where it wouldn't add more data.