I'm building a home automation controller and using the Sparkfun DS1307 based real time clock breakout board (I2C). Goes ok, but looses about 10 seconds per day. Disappointing considering my $9 Kmart no-name watch is accurate to a couple of seconds per month!.
Has anyone else had similar issues? Web searching shows that noise can cause the clock going fast and others suggest soldering the crystal straight onto the pin.
Greg Smith, Western Australia
One way would be to put a small variable capacitor across the crystal. About 22pF trimmer might do it.
I suggest that you contact the supplier before modifying the board. The crystal should not lose 10 seconds per day and if its faulty than you may be able to get the board replaced under warranty.
You have a microcontroller so you may as well add the 10s yourself rather than mocking the board with a trim capacitor. That is if the lag is consistent. If not, neither would work unless you find and correct the issue (e.g. clock stops when not powered, clock stops during reset).
To correct time in software you could convert to unix time, calculate the number days since sync and then multiply/add whatever daily lag you observe.
I've built my own RTC's boards on small cut-to-fit protoboards based on the Phillips PCF8563 I2C chip. These chips are low cost, easy to use and time is consistent to within +/- 2 seconds per month. Also the reference design includes a trimmer capacitor (total cost less than 5$).
As was suggested you should contact the manufacturer. It almost sounds like they
used the wrong crystal. The DS1307 (and the DS1337 that I use) are very
sensitive to the crystals series resistance and parallel capacitance. A lot
of watch crystals do not meet the specifications recommended in the datasheet.
If the vendor switched crystal suppliers there could be a component problem.
You can also check your application. Watch crystals are very susceptible to noise.
Check to see the relationship between the crystal and devices generating noise.
(* jcl *)
www: http://www.wiblocks.com
twitter: http://twitter.com/wiblocks
blog: http://luciani.org
Thanks guys for the replies - I'll check into these options. Something I noted lately is that the clock slows more when there is more I2C traffic. In my design, an external EEPROM hold all of the static data. When I send data to it via I2C (some 22kbyte worth) the clock looses a few seconds just over the few minutes send data to the EEPROM.
My design uses ethernet connectivity to my home server, so it's easy enough to send a corrected time every day (already got that part working with a specially crafted http request). But it's annoying that the drift is excessive.
I'll double check my code to make sure I'm not inadvertently stopping and starting the clock during program execution. First looks say no (but sometimes these things stare you in the face for a few days I guess).
Thanks again for your help.
Greg Smith
Something I noted lately is that the clock slows more when there is more I2C traffic. In my design, an external EEPROM hold all of the static data. When I send data to it via I2C (some 22kbyte worth) the clock looses a few seconds just over the few minutes send data to the EEPROM.
This sounds like noise from the I2C affecting the crystal. Check the way you are
running the I2C wires between your Arduino and the breakout board. Difficult
to diagnose over the net 
(* jcl *)
www: http://www.wiblocks.com
twitter: x.com
blog: http://luciani.org
i had the same issue recently, seemed to be caused by the power supply.
i changed to a wirewound PSU rather than switch mode and now seems accurate. The cold temperature also made it slow.