database/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-12-24 11:21:21 +03:00
Code Activity

Merge pchardin@bk-internal.mysql.com:/home/bk/mysql-4.1

Browse Source 
into  outpost.site:/home/cps/mysql/trees/4.1-runtime-bug9191


configure.in:
  Auto merged
include/my_time.h:
  Auto merged
mysql-test/r/func_time.result:
  Auto merged
mysql-test/r/rename.result:
  Auto merged
mysql-test/t/func_time.test:
  Auto merged
sql-common/my_time.c:
  Auto merged
sql/item_timefunc.cc:
  Auto merged
sql/time.cc:
  Auto merged
mysql-test/t/rename.test:
  choose one of the race problem solutions. It was solved
  differently in -runtime and mainstream
This commit is contained in:
unknown
2006-11-10 15:05:38 +03:00
parent facaaeb4c4 6cf8ceebbf
commit cb80733a89
19 changed files with 389 additions and 72 deletions
Download Patch File Download Diff File Expand all files Collapse all files

52
mysql-test/t/func_time.test
View File

@@ -236,16 +236,56 @@ select unix_timestamp(@a);
select unix_timestamp('1969-12-01 19:00:01');
#
# Test for bug #6439 "unix_timestamp() function returns wrong datetime
# values for too big argument" and bug #7515 "from_unixtime(0) now
# returns NULL instead of the epoch". unix_timestamp() should return error
# for too big or negative argument. It should return Epoch value for zero
# argument since it seems that many user's rely on this fact.
# Tests for bug #6439 "unix_timestamp() function returns wrong datetime
# values for too big argument", bug #7515 "from_unixtime(0) now
# returns NULL instead of the epoch" and bug #9191
# "TIMESTAMP/from_unixtime() no longer accepts 2^31-1."
# unix_timestamp() should return error for too big or negative argument.
# It should return Epoch value for zero argument since it seems that many
# users rely on this fact, from_unixtime() should work with values
# up to INT_MAX32 because of the same reason.
#
select from_unixtime(-1);
select from_unixtime(2145916800);
# check for from_unixtime(2^31-1) and from_unixtime(2^31)
select from_unixtime(2147483647);
select from_unixtime(2147483648);
select from_unixtime(0);
#
# Some more tests for bug #9191 "TIMESTAMP/from_unixtime() no
# longer accepts 2^31-1". Here we test that from_unixtime and
# unix_timestamp are consistent, when working with boundary dates.
#
select unix_timestamp(from_unixtime(2147483647));
select unix_timestamp(from_unixtime(2147483648));
# check for invalid dates
# bad year
select unix_timestamp('2039-01-20 01:00:00');
select unix_timestamp('1968-01-20 01:00:00');
# bad month
select unix_timestamp('2038-02-10 01:00:00');
select unix_timestamp('1969-11-20 01:00:00');
# bad day
select unix_timestamp('2038-01-20 01:00:00');
select unix_timestamp('1969-12-30 01:00:00');
#
# Check negative shift (we subtract several days for boundary dates during
# conversion).
select unix_timestamp('2038-01-17 12:00:00');
#
# Check positive shift. (it happens only on
# platfroms with unsigned time_t, such as QNX)
#
select unix_timestamp('1970-01-01 03:00:01');
# check bad date, close to the boundary (we cut them off in the very end)
select unix_timestamp('2038-01-19 07:14:07');
#
# Test types from + INTERVAL
#