mirror of
https://github.com/MariaDB/server.git
synced 2025-01-17 12:32:27 +01:00
d259ba4006
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.
59 lines
2.1 KiB
Text
59 lines
2.1 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');
|
|
|
|
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;
|