mariadb/mysql-test/t/timezone3.test
Georgi Kodinov f56e43ce52 Bug #39920: MySQL cannot deal with Leap Second expression in string literal.
Updated MySQL time handling code to react correctly on UTC leap second additions.
MySQL functions that return the OS current time, like e.g. CURDATE(), NOW() etc
will return :59:59 instead of :59:60 or 59:61.
As a result the reader will receive :59:59 for 2 or 3 consecutive seconds 
during the leap second.
This fix will not affect the values returned by UNIX_TIMESTAMP() for leap seconds.
But note that when converting the value returned by UNIX_TIMESTAMP() to broken 
down time the correction of leap seconds will still be applied.
Note that this fix will make a difference *only* if the OS is specially configured
to return leap seconds from the OS time calls or when using a MySQL time zone 
defintion that has leap seconds.
Even after this change date/time literals (or other broken down time 
representations) with leap seconds (ending on :59:60 or 59:61) will still be 
considered illegal and discarded by the server with an error or 
a warning depending on the sql mode.
Added a test case to demonstrate the effect of the fix.

mysql-test/r/timezone3.result:
  Bug #39920: test case
mysql-test/std_data/Moscow_leap:
  Bug #39920: updated the Moscow time zone to Dr. Olson's tzdata 2008i 
  to accomodate for the 2008 leap second
mysql-test/t/timezone3.test:
  Bug #39920: test case
sql/tztime.cc:
  Bug #39920: adjust leap seconds (:60 or :61) to :59
sql/tztime.h:
  Bug #39920: adjust leap seconds (:60 or :61) to :59
2008-12-01 16:18:35 +02:00

73 lines
2.5 KiB
Text

#
# 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');
insert into t1 values
(unix_timestamp('2009-01-01 02:59:59'),'2009-01-01 02:59:59'),
(unix_timestamp('2009-01-01 03:00:00'),'2009-01-01 03: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;
#
# Test Bug #39920: MySQL cannot deal with Leap Second expression in string
# literal
#
# 2009-01-01 02:59:59, 2009-01-01 02:59:60 and 2009-01-01 03:00:00
SELECT FROM_UNIXTIME(1230768022), FROM_UNIXTIME(1230768023), FROM_UNIXTIME(1230768024);
# End of 4.1 tests