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);

serg, please verify that my understanding ^^^ is correct.

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`.

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 |

+----------------------------+

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.