diff options
author | unknown <petr/cps@mysql.com/owlet.local> | 2006-11-01 16:47:40 +0300 |
---|---|---|
committer | unknown <petr/cps@mysql.com/owlet.local> | 2006-11-01 16:47:40 +0300 |
commit | 8a7bc052885494b83fed51d785d9fc4b1cfa9df1 (patch) | |
tree | e2642512c7a6f4cbdaa661730aca0413380e045e /mysql-test/r/func_time.result | |
parent | 5d46e2993389f3cffe2a37374ba61334f86f7e5e (diff) | |
download | mariadb-git-8a7bc052885494b83fed51d785d9fc4b1cfa9df1.tar.gz |
Fix Bug #9191 "TIMESTAMP/from_unixtime() no longer accepts 2^31-1"
(4.1 version, with post-review fixes)
The fix for another Bug (6439) limited FROM_UNIXTIME() to
TIMESTAMP_MAX_VALUE which is 2145916799 or 2037-12-01 23:59:59 GMT,
however unix timestamp in general is not considered to be limited
by this value. All dates up to power(2,31)-1 are valid.
This patch extends allowed TIMESTAMP range so, that max
TIMESTAMP value is power(2,31)-1. It also corrects
FROM_UNIXTIME() and UNIX_TIMESTAMP() functions, so that
max allowed UNIX_TIMESTAMP() is power(2,31)-1. FROM_UNIXTIME()
is fixed accordingly to allow conversion of dates up to
2038-01-19 03:14:07 UTC. The patch also fixes CONVERT_TZ()
function to allow extended range of dates.
The main problem solved in the patch is possible overflows
of variables, used in broken-time representation to time_t
conversion (required for UNIX_TIMESTAMP).
acinclude.m4:
Add new macro to check time_t range
configure.in:
Call the macro to check time_t range
include/my_time.h:
Move time-related defines to proper place.
Add a function to perform a rough check if
a TIMESTAMP value fits into the boundaries.
Note: it is defined as "static inline", as
otherwise libmysql won't compile (due to the
way how gcc handles "inline" directive).
mysql-test/r/func_time.result:
Update test result
mysql-test/r/timezone.result:
Update test result
mysql-test/r/timezone2.result:
Update test result
mysql-test/t/func_time.test:
Add test for Bug#9191 and update test to be consistent
with new TIMESTAMP boundaries
mysql-test/t/timezone.test:
Update old tests to be consistent
with new TIMESTAMP boundaries
mysql-test/t/timezone2.test:
Update tests for convert_tz to be consistent with new
TIMESTAMP boundaries
sql/item_timefunc.cc:
Fix convert_tz to allow dates from the new (extended)
TIMESTAMP range
sql/mysql_priv.h:
Move time handling defaults to my_time.h
sql-common/my_time.c:
Because of increased TIMESTAMP_MAX_VALUE overflows in my_system_gmt_sec()
became possible. Here we make it safe against the overflows by stepping
back from the boundary dates which are likely to trigger them.
sql/time.cc:
Update TIME_to_timestamp to allow conversion of
extended date range
sql/tztime.cc:
Fix new (4.1) implementation of broken-down time representation
to time_t conversion routine to avoid overflows during conversion
of boundary dates
mysql-test/r/timezone4.result:
New BitKeeper file ``mysql-test/r/timezone4.result''
mysql-test/t/timezone4-master.opt:
New BitKeeper file ``mysql-test/t/timezone4-master.opt''
mysql-test/t/timezone4.test:
New BitKeeper file ``mysql-test/t/timezone4.test''
Diffstat (limited to 'mysql-test/r/func_time.result')
-rw-r--r-- | mysql-test/r/func_time.result | 40 |
1 files changed, 38 insertions, 2 deletions
diff --git a/mysql-test/r/func_time.result b/mysql-test/r/func_time.result index 97dd8e243b2..6e3492f6744 100644 --- a/mysql-test/r/func_time.result +++ b/mysql-test/r/func_time.result @@ -483,12 +483,48 @@ unix_timestamp('1969-12-01 19:00:01') select from_unixtime(-1); from_unixtime(-1) NULL -select from_unixtime(2145916800); -from_unixtime(2145916800) +select from_unixtime(2147483647); +from_unixtime(2147483647) +2038-01-19 06:14:07 +select from_unixtime(2147483648); +from_unixtime(2147483648) NULL select from_unixtime(0); from_unixtime(0) 1970-01-01 03:00:00 +select unix_timestamp(from_unixtime(2147483647)); +unix_timestamp(from_unixtime(2147483647)) +2147483647 +select unix_timestamp(from_unixtime(2147483648)); +unix_timestamp(from_unixtime(2147483648)) +NULL +select unix_timestamp('2039-01-20 01:00:00'); +unix_timestamp('2039-01-20 01:00:00') +0 +select unix_timestamp('1968-01-20 01:00:00'); +unix_timestamp('1968-01-20 01:00:00') +0 +select unix_timestamp('2038-02-10 01:00:00'); +unix_timestamp('2038-02-10 01:00:00') +0 +select unix_timestamp('1969-11-20 01:00:00'); +unix_timestamp('1969-11-20 01:00:00') +0 +select unix_timestamp('2038-01-20 01:00:00'); +unix_timestamp('2038-01-20 01:00:00') +0 +select unix_timestamp('1969-12-30 01:00:00'); +unix_timestamp('1969-12-30 01:00:00') +0 +select unix_timestamp('2038-01-17 12:00:00'); +unix_timestamp('2038-01-17 12:00:00') +2147331600 +select unix_timestamp('1970-01-01 03:00:01'); +unix_timestamp('1970-01-01 03:00:01') +1 +select unix_timestamp('2038-01-19 07:14:07'); +unix_timestamp('2038-01-19 07:14:07') +0 CREATE TABLE t1 (datetime datetime, timestamp timestamp, date date, time time); INSERT INTO t1 values ("2001-01-02 03:04:05", "2002-01-02 03:04:05", "2003-01-02", "06:07:08"); SELECT * from t1; |