Fix for bug #6387 "Queried timestamp values do not match the inserted

value if server runs in time zone with leap seconds".

Now in my_gmt_sec() function we take into account difference between
our target and estimation in seconds part.


mysql-test/Makefile.am:
  Added mysql-test/std_data/Moscow_leap reuired by new timezone3.test
  to source distribution.
sql/time.cc:
  my_gmt_sec():
   When comparing our target broken-down datetime t value and proper 
   representation of our estimation *l_time we should take into account
   that they could differ in second part if we have time zone leap seconds.
   
   Also added comments about some assumptions used in this function.

1 files changed, 59 insertions, 0 deletions

diff --git a/mysql-test/t/timezone3.test b/mysql-test/t/timezone3.test
new file mode 100644
index 00000000000..8910783cd85
--- /dev/null
+++ b/mysql-test/t/timezone3.test
@@ -0,0 +1,59 @@
+#
+# Test of handling time zone with leap seconds.
+#
+# This test should be run with TZ=:$MYSQL_TEST_DIR/std_data/Moscow_leap
+# This implies that this test should be run only on systems that interpret 
+# characters after colon in TZ variable as path to zoneinfo file.
+#
+# Check that we have successfully set time zone with leap seconds.
+--require r/have_moscow_leap_timezone.require
+disable_query_log;
+select from_unixtime(1072904422);
+enable_query_log;
+
+# Initial clean-up
+--disable_warnings
+drop table if exists t1;
+--enable_warnings
+
+#
+# Let us check behavior of conversion from broken-down representation
+# to time_t representation, for normal, non-existent and ambigious dates
+# (This check is similar to the one in timezone2.test in 4.1)
+#
+create table t1 (i int, c varchar(20));
+# Normal value without DST
+insert into t1 values
+  (unix_timestamp("2004-01-01 00:00:00"), "2004-01-01 00:00:00");
+# Values around and in spring time-gap
+insert into t1 values
+  (unix_timestamp("2004-03-28 01:59:59"), "2004-03-28 01:59:59"),
+  (unix_timestamp("2004-03-28 02:30:00"), "2004-03-28 02:30:00"),
+  (unix_timestamp("2004-03-28 03:00:00"), "2004-03-28 03:00:00");
+# Normal value with DST
+insert into t1 values
+  (unix_timestamp('2004-05-01 00:00:00'),'2004-05-01 00:00:00');
+# Ambiguos values (also check for determenism)
+insert into t1 values
+  (unix_timestamp('2004-10-31 01:00:00'),'2004-10-31 01:00:00'),
+  (unix_timestamp('2004-10-31 02:00:00'),'2004-10-31 02:00:00'),
+  (unix_timestamp('2004-10-31 02:59:59'),'2004-10-31 02:59:59'),
+  (unix_timestamp('2004-10-31 04:00:00'),'2004-10-31 04:00:00'),
+  (unix_timestamp('2004-10-31 02:59:59'),'2004-10-31 02:59:59');
+# Test of leap
+insert into t1 values
+  (unix_timestamp('1981-07-01 03:59:59'),'1981-07-01 03:59:59'),
+  (unix_timestamp('1981-07-01 04:00:00'),'1981-07-01 04:00:00');
+
+select i, from_unixtime(i), c from t1;
+drop table t1;
+
+#
+# Test for bug #6387 "Queried timestamp values do not match the 
+# inserted". my_gmt_sec() function was not working properly if we
+# had time zone with leap seconds 
+#
+create table t1 (ts timestamp);
+insert into t1 values (19730101235900), (20040101235900);
+select * from t1;
+drop table t1;