mirror of
https://github.com/MariaDB/server.git
synced 2025-10-30 04:26:45 +03:00
8f36a23c00
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.
74 lines
2.5 KiB
Plaintext
74 lines
2.5 KiB
Plaintext
#
|
|
# 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
|