Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: Tim McDaniel (tmcdpanix.com)
Date: Tue Mar 04 2008 - 15:59:08 CST
Howdy -- new to the list.
BigCorp has a Bugzilla database that uses version 4.1.7-standard.
We've been taking backups using mysqldump. I thought to verify a
backup, in essence by
mysqldump bugzilla > B
mysql test < B
mysqldump test > T
diff B T
Everything is the same, except that the timestamps I've looked at are
all 22 or 23 seconds earlier in the test database than in the original
database. E.g., from a line-by-line diff of the mysqldump output:
line 697609, characters 15 on:
...sions VALUES ('val1','PROD1','2005-09-14 15:21:03');
...sions VALUES ('val1','PROD1','2005-09-14 15:21:41');
Specifically, the discrepancy appears to be the number of leap seconds
that were in effect at the point of the timestamp. E.g.,
line 697611, characters 15 on:
...sions VALUES ('val2','PROD2','2006-07-31 11:30:57');
...sions VALUES ('val2','PROD2','2006-07-31 11:30:34');
Since the timestamps are from 2003 on, and
<http://en.wikipedia.org/wiki/Leap_seconds> says that there's been
only one leap second added (at the end of 2005), and I've looked at
only a few dozen lines of diff, I can't tell for sure that that's it,
but it seems quite likely.
It's not an artifact of mysqldump in particular: select shows the same
I've tried Googling and "man mysqldump", but all I can find is
information on setting up timezone tables in MySQL.
In case it matters, "SELECT COUNT(*) FROM mysql.time_zone_name;"
returns 0, and
$ mysqladmin variables | grep zone
| system_time_zone | CST |
| time_zone | SYSTEM |
Is there some other configuration information I need to provide?
Tim McDaniel, tmcdpanix.com
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql