From 8a7bc052885494b83fed51d785d9fc4b1cfa9df1 Mon Sep 17 00:00:00 2001 From: unknown Date: Wed, 1 Nov 2006 16:47:40 +0300 Subject: 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'' --- sql-common/my_time.c | 124 +++++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 115 insertions(+), 9 deletions(-) (limited to 'sql-common') diff --git a/sql-common/my_time.c b/sql-common/my_time.c index 3c46a944ba9..8030fb07fbf 100644 --- a/sql-common/my_time.c +++ b/sql-common/my_time.c @@ -667,14 +667,27 @@ long calc_daynr(uint year,uint month,uint day) RETURN VALUE Time in UTC seconds since Unix Epoch representation. */ -my_time_t -my_system_gmt_sec(const MYSQL_TIME *t, long *my_timezone, bool *in_dst_time_gap) +my_time_t +my_system_gmt_sec(const MYSQL_TIME *t_src, long *my_timezone, + bool *in_dst_time_gap) { uint loop; - time_t tmp; + time_t tmp= 0; + int shift= 0; + MYSQL_TIME tmp_time; + MYSQL_TIME *t= &tmp_time; struct tm *l_time,tm_tmp; long diff, current_timezone; + /* + Use temp variable to avoid trashing input data, which could happen in + case of shift required for boundary dates processing. + */ + memcpy(&tmp_time, t_src, sizeof(MYSQL_TIME)); + + if (!validate_timestamp_range(t)) + return 0; + /* Calculate the gmt time based on current time and timezone The -1 on the end is to ensure that if have a date that exists twice @@ -688,13 +701,89 @@ my_system_gmt_sec(const MYSQL_TIME *t, long *my_timezone, bool *in_dst_time_gap) Note: this code assumes that our time_t estimation is not too far away from real value (we assume that localtime_r(tmp) will return something within 24 hrs from t) which is probably true for all current time zones. + + Note2: For the dates, which have time_t representation close to + MAX_INT32 (efficient time_t limit for supported platforms), we should + do a small trick to avoid overflow. That is, convert the date, which is + two days earlier, and then add these days to the final value. + + The same trick is done for the values close to 0 in time_t + representation for platfroms with unsigned time_t (QNX). + + To be more verbose, here is a sample (extracted from the code below): + (calc_daynr(2038, 1, 19) - (long) days_at_timestart)*86400L + 4*3600L + would return -2147480896 because of the long type overflow. In result + we would get 1901 year in localtime_r(), which is an obvious error. + + Alike problem raises with the dates close to Epoch. E.g. + (calc_daynr(1969, 12, 31) - (long) days_at_timestart)*86400L + 23*3600L + will give -3600. + + On some platforms, (E.g. on QNX) time_t is unsigned and localtime(-3600) + wil give us a date around 2106 year. Which is no good. + + Theoreticaly, there could be problems with the latter conversion: + there are at least two timezones, which had time switches near 1 Jan + of 1970 (because of political reasons). These are America/Hermosillo and + America/Mazatlan time zones. They changed their offset on + 1970-01-01 08:00:00 UTC from UTC-8 to UTC-7. For these zones + the code below will give incorrect results for dates close to + 1970-01-01, in the case OS takes into account these historical switches. + Luckily, it seems that we support only one platform with unsigned + time_t. It's QNX. And QNX does not support historical timezone data at all. + E.g. there are no /usr/share/zoneinfo/ files or any other mean to supply + historical information for localtime_r() etc. That is, the problem is not + relevant to QNX. + + We are safe with shifts close to MAX_INT32, as there are no known + time switches on Jan 2038 yet :) */ - tmp=(time_t) (((calc_daynr((uint) t->year,(uint) t->month,(uint) t->day) - - (long) days_at_timestart)*86400L + (long) t->hour*3600L + - (long) (t->minute*60 + t->second)) + (time_t) my_time_zone - - 3600); - current_timezone= my_time_zone; + if ((t->year == TIMESTAMP_MAX_YEAR) && (t->month == 1) && (t->day > 4)) + { + /* + Below we will pass (uint) (t->day - shift) to calc_daynr. + As we don't want to get an overflow here, we will shift + only safe dates. That's why we have (t->day > 4) above. + */ + t->day-= 2; + shift= 2; + } +#ifdef TIME_T_UNSIGNED + else + { + /* + We can get 0 in time_t representaion only on 1969, 31 of Dec or on + 1970, 1 of Jan. For both dates we use shift, which is added + to t->day in order to step out a bit from the border. + This is required for platforms, where time_t is unsigned. + As far as I know, among the platforms we support it's only QNX. + Note: the order of below if-statements is significant. + */ + + if ((t->year == TIMESTAMP_MIN_YEAR + 1) && (t->month == 1) + && (t->day <= 10)) + { + t->day+= 2; + shift= -2; + } + + if ((t->year == TIMESTAMP_MIN_YEAR) && (t->month == 12) + && (t->day == 31)) + { + t->year++; + t->month= 1; + t->day= 2; + shift= -2; + } + } +#endif + + tmp= (time_t) (((calc_daynr((uint) t->year, (uint) t->month, (uint) t->day) - + (long) days_at_timestart)*86400L + (long) t->hour*3600L + + (long) (t->minute*60 + t->second)) + (time_t) my_time_zone - + 3600); + current_timezone= my_time_zone; localtime_r(&tmp,&tm_tmp); l_time=&tm_tmp; for (loop=0; @@ -746,7 +835,24 @@ my_system_gmt_sec(const MYSQL_TIME *t, long *my_timezone, bool *in_dst_time_gap) *in_dst_time_gap= 1; } *my_timezone= current_timezone; - + + + /* shift back, if we were dealing with boundary dates */ + tmp+= shift*86400L; + + /* + This is possible for dates, which slightly exceed boundaries. + Conversion will pass ok for them, but we don't allow them. + First check will pass for platforms with signed time_t. + instruction above (tmp+= shift*86400L) could exceed + MAX_INT32 (== TIMESTAMP_MAX_VALUE) and overflow will happen. + So, tmp < TIMESTAMP_MIN_VALUE will be triggered. On platfroms + with unsigned time_t tmp+= shift*86400L might result in a number, + larger then TIMESTAMP_MAX_VALUE, so another check will work. + */ + if ((tmp < TIMESTAMP_MIN_VALUE) || (tmp > TIMESTAMP_MAX_VALUE)) + tmp= 0; +end: return (my_time_t) tmp; } /* my_system_gmt_sec */ -- cgit v1.2.1