Are you running pfSense on an ALIX 2/3 machine? Because they don't have a clock battery, the clock resets every time it's rebooted (though you can add a battery if you want to get your soldering iron out). If you're not using ALIX, then chances are your CMOS battery is dead. However NTPd is there precisely for the reason to compensate for the lack of a hardware clock.
However, when a clock is out of sync but a HUGE margin like this, NTP sort of goes into a panic mode and starts wondering whether to believe the system clock or reset it. The reason is NTP under normal operation will only fix drift by up to 2 seconds per second (this is at least under Linux, not sure about FreeBSD). When the date is completely out of whack, like 1970 vs 2009, it 'panics' (not a kernel panic, just an NTP panic) and its behaviour isn't really 100%.
The best way to deal with this is for pfSense to actually save the time at shutdown somewhere, and reset it (even if it's not totally accurate) at boot time, so NTP can then fix the time from this less-drifted reference rather than from 1970. The only way to fix it really is to manually set the time and then let NTP do it's thing.
Finally, pfSense also uses OpenNTPD, which is a cut down and considerably simpler and smaller version of NTP, which is more than fine if you're only running stratum2/3 with a pool.ntp.org reference. However if you want 'proper' NTP (especially with sub 1.0us accuracy and GPS/10MHz reference or being a pool host), then not having a dedicated box tuned for NTP and accuracy would be silly.
