Alexander Barkov added a comment - 2018-12-27 19:16 Alexey, I think that this patch is incomplete: https://github.com/MariaDB/server/pull/1049/commits/6d95db7ee7e4fd4283714ce21c1464b70564e50c It's not enough to add a test for TIME_NO_ZERO_IN_DATE|TIME_NO_ZERO_DATE. It should probably also test that the value is in the supported TIMESTAMP range: from '1970-01-01 00:00:01' (UTC) to '2038-01-19 05:14:07' (UTC). You can check it using either TIME_to_timestamp() or using this Timestamp constructor: Timestamp(THD *thd, const MYSQL_TIME *ltime, uint *error_code);

Alexander Barkov added a comment - 2018-12-27 19:17 serg , please verify that my understanding ^^^ is correct.

Aleksey Midenkov added a comment - 2018-12-27 22:06 If we restrict `system_versioning_asof` to some range, that means we also must restrict `FOR SYSTEM_TIME` values in queries to that range. OTOH TIMESTAMP range will be expanded in `TIMESTAMP WITH TIME ZONE`.

Alexander Barkov added a comment - 2018-12-28 08:36 - edited I think the variable system_versioning_asof should be of the data type TIMESTAMP, not DATETIME, and therefore store the timestamp value in my_time_t format, and thus be in the supported TIMESTAMP range. Something like this: struct vers_asof_timestamp_t { ulong type; Timeval tv; vers_asof_timestamp_t() : type(SYSTEM_TIME_UNSPECIFIED), tv(0, 0) {} }; We'll later change it to TIMESTAMP WITH TIME ZONE, when we add the latter. Note, this script: SET system_versioning_asof= '2001-01-01 00:00:00' ; SET time_zone= '+04:00' ; SELECT @@system_versioning_asof; SET time_zone= '-10:00' ; SELECT @@system_versioning_asof; returns +----------------------------+ | @@system_versioning_asof | +----------------------------+ | 2001-01-01 00:00:00.000000 | +----------------------------+ for both SELECT queries. I'd expect the second SELECT query to return a different value, 14 hours behind: +----------------------------+ | @@system_versioning_asof | +----------------------------+ | 2000-12-31 10:00:00.000000 | +----------------------------+

Robert Bindar added a comment - 2019-12-13 11:47 Hi midenok , are you still willing to work on this? There are 2 PRs open for this bug ( 1049 and 1048 ) that I'd very much like to see solved.