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''

1 files changed, 5 insertions, 5 deletions

diff --git a/mysql-test/t/timezone2.test b/mysql-test/t/timezone2.test
index 523249a3a2c..43f9a944be1 100644
--- a/mysql-test/t/timezone2.test
+++ b/mysql-test/t/timezone2.test
@@ -107,21 +107,21 @@ create table t1 (ts timestamp);
 set time_zone='UTC';
 insert into t1 values ('0000-00-00 00:00:00'),('1969-12-31 23:59:59'),
                       ('1970-01-01 00:00:00'),('1970-01-01 00:00:01'),
-                      ('2037-12-31 23:59:59'),('2038-01-01 00:00:00');
+                      ('2038-01-19 03:14:07'),('2038-01-19 03:14:08');
 select * from t1;
 delete from t1;
 # MET time zone has range shifted by one hour
 set time_zone='MET';
 insert into t1 values ('0000-00-00 00:00:00'),('1970-01-01 00:30:00'),
                       ('1970-01-01 01:00:00'),('1970-01-01 01:00:01'),
-                      ('2038-01-01 00:59:59'),('2038-01-01 01:00:00');
+                      ('2038-01-19 04:14:07'),('2038-01-19 04:14:08');
 select * from t1;
 delete from t1;
 # same for +01:30 time zone
 set time_zone='+01:30';
 insert into t1 values ('0000-00-00 00:00:00'),('1970-01-01 01:00:00'),
                       ('1970-01-01 01:30:00'),('1970-01-01 01:30:01'),
-                      ('2038-01-01 01:29:59'),('2038-01-01 01:30:00');
+                      ('2038-01-19 04:44:07'),('2038-01-19 04:44:08');
 select * from t1;
 
 drop table t1;
@@ -171,8 +171,8 @@ select convert_tz('2003-10-26 01:00:00', 'MET', 'UTC');
 select convert_tz('2003-10-26 02:00:00', 'MET', 'UTC');
 select convert_tz('2003-10-26 02:59:59', 'MET', 'UTC');
 select convert_tz('2003-10-26 04:00:00', 'MET', 'UTC');
-select convert_tz('2038-01-01 00:59:59', 'MET', 'UTC');
-select convert_tz('2038-01-01 01:00:00', 'MET', 'UTC');
+select convert_tz('2038-01-19 04:14:07', 'MET', 'UTC');
+select convert_tz('2038-01-19 04:14:08', 'MET', 'UTC');
 select convert_tz('2103-01-01 04:00:00', 'MET', 'UTC');
 
 # Let us test variable time zone argument