mirror of
https://github.com/MariaDB/server.git
synced 2025-01-27 09:14:17 +01:00
cad881ab10
Reported in Debian bug #1084293, from the tzdata changelog: * Upstream obsoleted the System V names CET, CST6CDT, EET, EST*, HST, MET, MST*, PST8PDT, and WET. They are symlinks now. Move those zones to tzdata-legacy and update /etc/localtime on package update to the new names. Please use Etc/GMT* in case you want to avoid DST changes. As such the timezone output started to output CET (or CEST) as the current timezone. Due to the way the test was written, its only possible to hit this error when running mtr from a package. The internals of MTR fix the timezone so this will never be hit in a build. As such, added Europe/Budapest as the Central Europe Standard Time (per sql/win_tzname_data.h and its derived unicode.org source) as timezone, hard fixed by timezone.opt file so it will always run. The have_cet_timezone is there to check the zonedata is installed (was absent on buildbot Ubuntu 22.04 and Windows). As replace result to the CET output and treat MET/MEST as the same while its on its way out. Thanks Santiago Vila for the bug report and Otto for forwarding it.
65 lines
2 KiB
Text
65 lines
2 KiB
Text
#
|
|
# Test of SYSTEM time zone handling ( for my_system_gmt_sec()).
|
|
# This script must have zonedata for CET
|
|
-- require include/have_cet_timezone.require
|
|
|
|
disable_query_log;
|
|
select FROM_UNIXTIME(24*3600);
|
|
enable_query_log;
|
|
|
|
# Initialization
|
|
--disable_warnings
|
|
DROP TABLE IF EXISTS t1;
|
|
--enable_warnings
|
|
|
|
# The following is because of daylight saving time
|
|
--replace_result MEST CET MET CET
|
|
show variables like "system_time_zone";
|
|
|
|
#
|
|
# Test unix timestamp
|
|
#
|
|
select @a:=FROM_UNIXTIME(1);
|
|
select unix_timestamp(@a);
|
|
|
|
#
|
|
# Test of some values, including some with daylight saving time
|
|
#
|
|
|
|
CREATE TABLE t1 (ts int);
|
|
INSERT INTO t1 (ts) VALUES (Unix_timestamp('2002-10-27 01:00'));
|
|
INSERT INTO t1 (ts) VALUES (Unix_timestamp('2002-10-27 02:00'));
|
|
INSERT INTO t1 (ts) VALUES (Unix_timestamp('2002-10-27 03:00'));
|
|
INSERT INTO t1 (ts) VALUES (Unix_timestamp('2002-10-27 02:00'));
|
|
INSERT INTO t1 (ts) VALUES (Unix_timestamp('2002-10-27 01:00'));
|
|
INSERT INTO t1 (ts) VALUES (Unix_timestamp('2002-10-27 02:00'));
|
|
INSERT INTO t1 (ts) VALUES (Unix_timestamp('2003-03-30 02:59:59'));
|
|
INSERT INTO t1 (ts) VALUES (Unix_timestamp('2003-03-30 03:00:00'));
|
|
INSERT INTO t1 (ts) VALUES (Unix_timestamp('2003-03-30 03:59:59'));
|
|
INSERT INTO t1 (ts) VALUES (Unix_timestamp('2003-03-30 04:00:01'));
|
|
|
|
SELECT ts,from_unixtime(ts) FROM t1;
|
|
DROP TABLE t1;
|
|
|
|
|
|
#
|
|
# Test of warning for spring time-gap values for system time zone
|
|
#
|
|
CREATE TABLE t1 (ts timestamp);
|
|
INSERT INTO t1 (ts) VALUES ('2003-03-30 01:59:59'),
|
|
('2003-03-30 02:59:59'),
|
|
('2003-03-30 03:00:00');
|
|
DROP TABLE t1;
|
|
|
|
#
|
|
# Test for fix for Bug#2523 Check that boundary dates are processed
|
|
# correctly.
|
|
#
|
|
select unix_timestamp('1970-01-01 01:00:00'),
|
|
unix_timestamp('1970-01-01 01:00:01'),
|
|
unix_timestamp('2038-01-19 04:14:07'),
|
|
unix_timestamp('2038-01-19 04:14:08');
|
|
|
|
select unix_timestamp('1969-12-31 23:59:59'), unix_timestamp('1970-01-01 00:00:00'), unix_timestamp('1970-01-01 00:59:59');
|
|
|
|
# End of 4.1 tests
|