OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Problems with timestamp and leap seconds?

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
thing.

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?
Any hints?

--
Tim McDaniel, tmcdpanix.com

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql