Uploaded image for project: 'MariaDB Connector/ODBC'
  1. MariaDB Connector/ODBC
  2. ODBC-417

Year 2038 issue executing prepared UPDATE statement via ODBC when binding timestamps

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Duplicate
    • 3.1.14
    • 3.1.15
    • General
    • OS: Windows 10, CentOS 6, CentOS 7, Ubuntu 18.04 , Windows 2012
      ODBC Connector 3.0 & 3.1.7

    Description

      We were upgrading to 10.4.12 recently and found an year 2038 issue in the integration tests.
      This is a regression from 10.4.0 which is known good.
      First, let me state that I already bisected the commit that introduced the changed behaviour which is:
      https://github.com/MariaDB/server/commit/34eb98387f
      MDEV-13995
      Probably the best to look at this would be @"Alexander Barkov"

      I changed a MSDN example to do the following
      Steps to reproduce:
      Setup

      CREATE DATABASE IF NOT EXISTS `test` CHARACTER SET utf8 COLLATE utf8_bin;
      		 
      USE test;
      		 
       
      		 
      CREATE OR REPLACE TABLE table_name (id INTEGER, a DateTime(3), b Timestamp(3));
      		 
      INSERT INTO table_name (id,a,b) VALUES(1, NULL, NULL);

      This is working (log_direct.trace is the corresponding dbuglog):

      UPDATE table_name SET a = TIMESTAMP'2039-12-26 00:00:00' WHERE (id = 1)

      Result:

      id|a                  |b                  |
      		 
      --|-------------------|-------------------|
      		 
       1|2039-12-26 00:00:00|2020-06-10 07:12:11|

      This is will set NULL for timestamps affected by the year 2038 issue ( log_prepared.trace is the corresponding dbug log)
      (pseudocode, the complete code will be in the reproducer): 

      SQLPrepare(hStmt, "UPDATE table_name SET a = ? WHERE (id = ?)")
      		 
      timestamp.year = 2039;  
      timestamp.month = 12;  
      timestamp.day = 26;  
      timestamp.hour = 0;  
      timestamp.minute = 0;  
      timestamp.second = 0;  
      timestamp.fraction = 100; 
      SQLLEN timestamp_len = sizeof(timestamp);
      		 
      SQLBindParameter(hStmt, ++paramNum, SQL_PARAM_INPUT, SQL_C_TYPE_TIMESTAMP, SQL_TYPE_TIMESTAMP, 27, 0, &timestamp, 0, &timestamp_len);
      		 
       
      		 
      SQLINTEGER sqlint = 1;
      		 
      SQLLEN int_len = sizeof(sqlint);
      		 
      SQLBindParameter(hStmt, ++paramNum, SQL_PARAM_INPUT, SQL_C_SLONG, SQL_INTEGER, 0, 0, &sqlint, 0, &int_len);
      		 
       
      		 
      SQLExecute(hStmt)

      Result:

      | id          | a                       | b                        |
      		 
      |           1 | <NULL>                  | 2020-06-09 13:28:17.098  |

      If you want to use the reproducer program, it can be compiled with
      cl /EHsc /DEBUG:FULL /DUNICODE /D_UNICODE user32.lib odbc32.lib /link /SUBSYSTEM:CONSOLE replicate.cpp
      and run with
      replicate.exe "DSN=DebugMDB; Uid=root; Pwd="

      I wanted to write a test but could not reproduce this with prepared SQL statments like so:

      CREATE DATABASE IF NOT EXISTS `test` CHARACTER SET utf8 COLLATE utf8_bin;
      		 
      USE test;
      		 
       
      		 
      CREATE OR REPLACE TABLE t1 (id INTEGER, a DateTime, b Timestamp);
      		 
      INSERT INTO t1 (id,a,b) VALUES(1, NULL, NULL);
      		 
      -- SET SESSION debug_dbug = 'd,enter,exit,error,warning,info,loop:t:F:L:O,data/log.trace';
      		 
      PREPARE stmt FROM 'UPDATE t1 SET a = ? WHERE (id = ?)';
      		 
      set @a=TIMESTAMP'2039-12-26 00:00:00', @b=1;
      		 
      execute stmt using @a,@b;
      		 
      -- SET SESSION debug_dbug = '';
      		 
      SELECT * FROM t1;
      		 
      DROP TABLE t1;
      		 
      DEALLOCATE PREPARE stmt;

      Result:

      id|a                  |b                  |
      		 
      --|-------------------|-------------------|
      		 
       1|2039-12-26 00:00:00|2020-06-10 07:09:16|

      Attachments

        1. log_direct.trace
          64 kB
        2. log_prepared.trace
          95 kB
        3. replicate.cpp
          22 kB
        4. replicate-linux.cpp
          22 kB

        Issue Links

          duplicates

          Bug - A problem which impairs or prevents the functions of the product. ODBC-345 Date values between 1970 and 2038 not saved

          • Major - Major loss of function.
          • Closed
          relates to

          Bug - A problem which impairs or prevents the functions of the product. MDEV-13995 MAX(timestamp) returns a wrong result near DST change

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            mwax Michael Walloch (Inactive) created issue -
            mwax Michael Walloch (Inactive) made changes -
            Field Original Value New Value
            Attachment log_prepared.trace [ 52121 ]
            Attachment log_direct.trace [ 52122 ]
            mwax Michael Walloch (Inactive) made changes -
            Description We were upgrading to 10.4.12 recently and found an year 2038 issue in the integration tests.
            First, let me state that I already bisected the commit that introduced the changed behaviour which is:
            https://github.com/MariaDB/server/commit/34eb98387f
            MDEV-13995

            I changed a MSDN example to do the following
            Steps to reproduce:
            Setup
            {code:SQL}
            CREATE DATABASE IF NOT EXISTS `test` CHARACTER SET utf8 COLLATE utf8_bin;
            USE test;

            CREATE OR REPLACE TABLE table_name (id INTEGER, a DateTime(3), b Timestamp(3));
            INSERT INTO table_name (id,a,b) VALUES(1, NULL, NULL);
            {code}

            This is working:
            {code:SQL}
            UPDATE table_name SET a = TIMESTAMP'2039-12-26 00:00:00' WHERE (id = 1)
            {code}

            This is will set NULL for timestamps affected by the year 2038 issue
            (pseudocode, the complete code will be in the reproducer):
            {code:c}
            SQLPrepare(hStmt, "UPDATE table_name SET a = ? WHERE (id = ?)")
            timestamp.year = 2039;
            timestamp.month = 12;
            timestamp.day = 26;
            timestamp.hour = 0;
            timestamp.minute = 0;
            timestamp.second = 0;
            timestamp.fraction = 100;
            SQLLEN timestamp_len = sizeof(timestamp);
            SQLBindParameter(hStmt, ++paramNum, SQL_PARAM_INPUT, SQL_C_TYPE_TIMESTAMP, SQL_TYPE_TIMESTAMP, 27, 0, &timestamp, 0, &timestamp_len);

            SQLINTEGER sqlint = 1;
            SQLLEN int_len = sizeof(sqlint);
            SQLBindParameter(hStmt, ++paramNum, SQL_PARAM_INPUT, SQL_C_SLONG, SQL_INTEGER, 0, 0, &sqlint, 0, &int_len);

            SQLExecute(hStmt)
            {code}

            If you want to use the reproducer program, it can be compiled with
            {{cl /EHsc /DEBUG:FULL /DUNICODE /D_UNICODE user32.lib odbc32.lib /link /SUBSYSTEM:CONSOLE replicate.cpp}}
            and run with
            {{replicate.exe "DSN=DebugMDB; Uid=root; Pwd="}}

            		We were upgrading to 10.4.12 recently and found an year 2038 issue in the integration tests.
            First, let me state that I already bisected the commit that introduced the changed behaviour which is:
            https://github.com/MariaDB/server/commit/34eb98387f
            MDEV-13995

            I changed a MSDN example to do the following
            Steps to reproduce:
            Setup
            {code:SQL}
            CREATE DATABASE IF NOT EXISTS `test` CHARACTER SET utf8 COLLATE utf8_bin;
            USE test;

            CREATE OR REPLACE TABLE table_name (id INTEGER, a DateTime(3), b Timestamp(3));
            INSERT INTO table_name (id,a,b) VALUES(1, NULL, NULL);
            {code}

            This is working ([^log_direct.trace] is the corresponding log):
            {code:SQL}
            UPDATE table_name SET a = TIMESTAMP'2039-12-26 00:00:00' WHERE (id = 1)
            {code}

            This is will set NULL for timestamps affected by the year 2038 issue ( [^log_prepared.trace] is the corresponding log)
            (pseudocode, the complete code will be in the reproducer):
            {code:c}
            SQLPrepare(hStmt, "UPDATE table_name SET a = ? WHERE (id = ?)")
            timestamp.year = 2039;
            timestamp.month = 12;
            timestamp.day = 26;
            timestamp.hour = 0;
            timestamp.minute = 0;
            timestamp.second = 0;
            timestamp.fraction = 100;
            SQLLEN timestamp_len = sizeof(timestamp);
            SQLBindParameter(hStmt, ++paramNum, SQL_PARAM_INPUT, SQL_C_TYPE_TIMESTAMP, SQL_TYPE_TIMESTAMP, 27, 0, &timestamp, 0, &timestamp_len);

            SQLINTEGER sqlint = 1;
            SQLLEN int_len = sizeof(sqlint);
            SQLBindParameter(hStmt, ++paramNum, SQL_PARAM_INPUT, SQL_C_SLONG, SQL_INTEGER, 0, 0, &sqlint, 0, &int_len);

            SQLExecute(hStmt)
            {code}

            If you want to use the reproducer program, it can be compiled with
            {{cl /EHsc /DEBUG:FULL /DUNICODE /D_UNICODE user32.lib odbc32.lib /link /SUBSYSTEM:CONSOLE replicate.cpp}}
            and run with
            {{replicate.exe "DSN=DebugMDB; Uid=root; Pwd="}}

            mwax Michael Walloch (Inactive) made changes -
            Description We were upgrading to 10.4.12 recently and found an year 2038 issue in the integration tests.
            First, let me state that I already bisected the commit that introduced the changed behaviour which is:
            https://github.com/MariaDB/server/commit/34eb98387f
            MDEV-13995

            I changed a MSDN example to do the following
            Steps to reproduce:
            Setup
            {code:SQL}
            CREATE DATABASE IF NOT EXISTS `test` CHARACTER SET utf8 COLLATE utf8_bin;
            USE test;

            CREATE OR REPLACE TABLE table_name (id INTEGER, a DateTime(3), b Timestamp(3));
            INSERT INTO table_name (id,a,b) VALUES(1, NULL, NULL);
            {code}

            This is working ([^log_direct.trace] is the corresponding log):
            {code:SQL}
            UPDATE table_name SET a = TIMESTAMP'2039-12-26 00:00:00' WHERE (id = 1)
            {code}

            This is will set NULL for timestamps affected by the year 2038 issue ( [^log_prepared.trace] is the corresponding log)
            (pseudocode, the complete code will be in the reproducer):
            {code:c}
            SQLPrepare(hStmt, "UPDATE table_name SET a = ? WHERE (id = ?)")
            timestamp.year = 2039;
            timestamp.month = 12;
            timestamp.day = 26;
            timestamp.hour = 0;
            timestamp.minute = 0;
            timestamp.second = 0;
            timestamp.fraction = 100;
            SQLLEN timestamp_len = sizeof(timestamp);
            SQLBindParameter(hStmt, ++paramNum, SQL_PARAM_INPUT, SQL_C_TYPE_TIMESTAMP, SQL_TYPE_TIMESTAMP, 27, 0, &timestamp, 0, &timestamp_len);

            SQLINTEGER sqlint = 1;
            SQLLEN int_len = sizeof(sqlint);
            SQLBindParameter(hStmt, ++paramNum, SQL_PARAM_INPUT, SQL_C_SLONG, SQL_INTEGER, 0, 0, &sqlint, 0, &int_len);

            SQLExecute(hStmt)
            {code}

            If you want to use the reproducer program, it can be compiled with
            {{cl /EHsc /DEBUG:FULL /DUNICODE /D_UNICODE user32.lib odbc32.lib /link /SUBSYSTEM:CONSOLE replicate.cpp}}
            and run with
            {{replicate.exe "DSN=DebugMDB; Uid=root; Pwd="}}

            		We were upgrading to 10.4.12 recently and found an year 2038 issue in the integration tests.
            First, let me state that I already bisected the commit that introduced the changed behaviour which is:
            https://github.com/MariaDB/server/commit/34eb98387f
            MDEV-13995

            I changed a MSDN example to do the following
            Steps to reproduce:
            Setup
            {code:SQL}
            CREATE DATABASE IF NOT EXISTS `test` CHARACTER SET utf8 COLLATE utf8_bin;
            USE test;

            CREATE OR REPLACE TABLE table_name (id INTEGER, a DateTime(3), b Timestamp(3));
            INSERT INTO table_name (id,a,b) VALUES(1, NULL, NULL);
            {code}

            This is working ([^log_direct.trace] is the corresponding dbuglog):
            {code:SQL}
            UPDATE table_name SET a = TIMESTAMP'2039-12-26 00:00:00' WHERE (id = 1)
            {code}

            This is will set NULL for timestamps affected by the year 2038 issue ( [^log_prepared.trace] is the corresponding dbug log)
            (pseudocode, the complete code will be in the reproducer):
            {code:c}
            SQLPrepare(hStmt, "UPDATE table_name SET a = ? WHERE (id = ?)")
            timestamp.year = 2039;
            timestamp.month = 12;
            timestamp.day = 26;
            timestamp.hour = 0;
            timestamp.minute = 0;
            timestamp.second = 0;
            timestamp.fraction = 100;
            SQLLEN timestamp_len = sizeof(timestamp);
            SQLBindParameter(hStmt, ++paramNum, SQL_PARAM_INPUT, SQL_C_TYPE_TIMESTAMP, SQL_TYPE_TIMESTAMP, 27, 0, &timestamp, 0, &timestamp_len);

            SQLINTEGER sqlint = 1;
            SQLLEN int_len = sizeof(sqlint);
            SQLBindParameter(hStmt, ++paramNum, SQL_PARAM_INPUT, SQL_C_SLONG, SQL_INTEGER, 0, 0, &sqlint, 0, &int_len);

            SQLExecute(hStmt)
            {code}

            If you want to use the reproducer program, it can be compiled with
            {{cl /EHsc /DEBUG:FULL /DUNICODE /D_UNICODE user32.lib odbc32.lib /link /SUBSYSTEM:CONSOLE replicate.cpp}}
            and run with
            {{replicate.exe "DSN=DebugMDB; Uid=root; Pwd="}}

            mwax Michael Walloch (Inactive) made changes -
            Description We were upgrading to 10.4.12 recently and found an year 2038 issue in the integration tests.
            First, let me state that I already bisected the commit that introduced the changed behaviour which is:
            https://github.com/MariaDB/server/commit/34eb98387f
            MDEV-13995

            I changed a MSDN example to do the following
            Steps to reproduce:
            Setup
            {code:SQL}
            CREATE DATABASE IF NOT EXISTS `test` CHARACTER SET utf8 COLLATE utf8_bin;
            USE test;

            CREATE OR REPLACE TABLE table_name (id INTEGER, a DateTime(3), b Timestamp(3));
            INSERT INTO table_name (id,a,b) VALUES(1, NULL, NULL);
            {code}

            This is working ([^log_direct.trace] is the corresponding dbuglog):
            {code:SQL}
            UPDATE table_name SET a = TIMESTAMP'2039-12-26 00:00:00' WHERE (id = 1)
            {code}

            This is will set NULL for timestamps affected by the year 2038 issue ( [^log_prepared.trace] is the corresponding dbug log)
            (pseudocode, the complete code will be in the reproducer):
            {code:c}
            SQLPrepare(hStmt, "UPDATE table_name SET a = ? WHERE (id = ?)")
            timestamp.year = 2039;
            timestamp.month = 12;
            timestamp.day = 26;
            timestamp.hour = 0;
            timestamp.minute = 0;
            timestamp.second = 0;
            timestamp.fraction = 100;
            SQLLEN timestamp_len = sizeof(timestamp);
            SQLBindParameter(hStmt, ++paramNum, SQL_PARAM_INPUT, SQL_C_TYPE_TIMESTAMP, SQL_TYPE_TIMESTAMP, 27, 0, &timestamp, 0, &timestamp_len);

            SQLINTEGER sqlint = 1;
            SQLLEN int_len = sizeof(sqlint);
            SQLBindParameter(hStmt, ++paramNum, SQL_PARAM_INPUT, SQL_C_SLONG, SQL_INTEGER, 0, 0, &sqlint, 0, &int_len);

            SQLExecute(hStmt)
            {code}

            If you want to use the reproducer program, it can be compiled with
            {{cl /EHsc /DEBUG:FULL /DUNICODE /D_UNICODE user32.lib odbc32.lib /link /SUBSYSTEM:CONSOLE replicate.cpp}}
            and run with
            {{replicate.exe "DSN=DebugMDB; Uid=root; Pwd="}}

            		We were upgrading to 10.4.12 recently and found an year 2038 issue in the integration tests.
            First, let me state that I already bisected the commit that introduced the changed behaviour which is:
            https://github.com/MariaDB/server/commit/34eb98387f
            MDEV-13995

            I changed a MSDN example to do the following
            Steps to reproduce:
            Setup
            {code:SQL}
            CREATE DATABASE IF NOT EXISTS `test` CHARACTER SET utf8 COLLATE utf8_bin;
            USE test;

            CREATE OR REPLACE TABLE table_name (id INTEGER, a DateTime(3), b Timestamp(3));
            INSERT INTO table_name (id,a,b) VALUES(1, NULL, NULL);
            {code}

            This is working ([^log_direct.trace] is the corresponding dbuglog):
            {code:SQL}
            UPDATE table_name SET a = TIMESTAMP'2039-12-26 00:00:00' WHERE (id = 1)
            {code}

            This is will set NULL for timestamps affected by the year 2038 issue ( [^log_prepared.trace] is the corresponding dbug log)
            (pseudocode, the complete code will be in the reproducer):
            {code:c}
            SQLPrepare(hStmt, "UPDATE table_name SET a = ? WHERE (id = ?)")
            timestamp.year = 2039;
            timestamp.month = 12;
            timestamp.day = 26;
            timestamp.hour = 0;
            timestamp.minute = 0;
            timestamp.second = 0;
            timestamp.fraction = 100;
            SQLLEN timestamp_len = sizeof(timestamp);
            SQLBindParameter(hStmt, ++paramNum, SQL_PARAM_INPUT, SQL_C_TYPE_TIMESTAMP, SQL_TYPE_TIMESTAMP, 27, 0, &timestamp, 0, &timestamp_len);

            SQLINTEGER sqlint = 1;
            SQLLEN int_len = sizeof(sqlint);
            SQLBindParameter(hStmt, ++paramNum, SQL_PARAM_INPUT, SQL_C_SLONG, SQL_INTEGER, 0, 0, &sqlint, 0, &int_len);

            SQLExecute(hStmt)
            {code}

            If you want to use the reproducer program, it can be compiled with
            {{cl /EHsc /DEBUG:FULL /DUNICODE /D_UNICODE user32.lib odbc32.lib /link /SUBSYSTEM:CONSOLE replicate.cpp}}
            and run with
            {{replicate.exe "DSN=DebugMDB; Uid=root; Pwd="}}

            I wanted to write a test but could not reproduce this with prepared SQL statments like so:

            {code:SQL}
            CREATE DATABASE IF NOT EXISTS `test` CHARACTER SET utf8 COLLATE utf8_bin;
            USE test;

            CREATE OR REPLACE TABLE table_name (id INTEGER, a DateTime(3), b Timestamp(3));
            INSERT INTO table_name (id,a,b) VALUES(1, NULL, NULL);


            {code}
            mwax Michael Walloch (Inactive) made changes -
            Description We were upgrading to 10.4.12 recently and found an year 2038 issue in the integration tests.
            First, let me state that I already bisected the commit that introduced the changed behaviour which is:
            https://github.com/MariaDB/server/commit/34eb98387f
            MDEV-13995

            I changed a MSDN example to do the following
            Steps to reproduce:
            Setup
            {code:SQL}
            CREATE DATABASE IF NOT EXISTS `test` CHARACTER SET utf8 COLLATE utf8_bin;
            USE test;

            CREATE OR REPLACE TABLE table_name (id INTEGER, a DateTime(3), b Timestamp(3));
            INSERT INTO table_name (id,a,b) VALUES(1, NULL, NULL);
            {code}

            This is working ([^log_direct.trace] is the corresponding dbuglog):
            {code:SQL}
            UPDATE table_name SET a = TIMESTAMP'2039-12-26 00:00:00' WHERE (id = 1)
            {code}

            This is will set NULL for timestamps affected by the year 2038 issue ( [^log_prepared.trace] is the corresponding dbug log)
            (pseudocode, the complete code will be in the reproducer):
            {code:c}
            SQLPrepare(hStmt, "UPDATE table_name SET a = ? WHERE (id = ?)")
            timestamp.year = 2039;
            timestamp.month = 12;
            timestamp.day = 26;
            timestamp.hour = 0;
            timestamp.minute = 0;
            timestamp.second = 0;
            timestamp.fraction = 100;
            SQLLEN timestamp_len = sizeof(timestamp);
            SQLBindParameter(hStmt, ++paramNum, SQL_PARAM_INPUT, SQL_C_TYPE_TIMESTAMP, SQL_TYPE_TIMESTAMP, 27, 0, &timestamp, 0, &timestamp_len);

            SQLINTEGER sqlint = 1;
            SQLLEN int_len = sizeof(sqlint);
            SQLBindParameter(hStmt, ++paramNum, SQL_PARAM_INPUT, SQL_C_SLONG, SQL_INTEGER, 0, 0, &sqlint, 0, &int_len);

            SQLExecute(hStmt)
            {code}

            If you want to use the reproducer program, it can be compiled with
            {{cl /EHsc /DEBUG:FULL /DUNICODE /D_UNICODE user32.lib odbc32.lib /link /SUBSYSTEM:CONSOLE replicate.cpp}}
            and run with
            {{replicate.exe "DSN=DebugMDB; Uid=root; Pwd="}}

            I wanted to write a test but could not reproduce this with prepared SQL statments like so:

            {code:SQL}
            CREATE DATABASE IF NOT EXISTS `test` CHARACTER SET utf8 COLLATE utf8_bin;
            USE test;

            CREATE OR REPLACE TABLE table_name (id INTEGER, a DateTime(3), b Timestamp(3));
            INSERT INTO table_name (id,a,b) VALUES(1, NULL, NULL);


            {code}             		We were upgrading to 10.4.12 recently and found an year 2038 issue in the integration tests.
            First, let me state that I already bisected the commit that introduced the changed behaviour which is:
            https://github.com/MariaDB/server/commit/34eb98387f
            MDEV-13995

            I changed a MSDN example to do the following
            Steps to reproduce:
            Setup
            {code:SQL}
            CREATE DATABASE IF NOT EXISTS `test` CHARACTER SET utf8 COLLATE utf8_bin;
            USE test;

            CREATE OR REPLACE TABLE table_name (id INTEGER, a DateTime(3), b Timestamp(3));
            INSERT INTO table_name (id,a,b) VALUES(1, NULL, NULL);
            {code}

            This is working ([^log_direct.trace] is the corresponding dbuglog):
            {code:SQL}
            UPDATE table_name SET a = TIMESTAMP'2039-12-26 00:00:00' WHERE (id = 1)
            {code}

            This is will set NULL for timestamps affected by the year 2038 issue ( [^log_prepared.trace] is the corresponding dbug log)
            (pseudocode, the complete code will be in the reproducer):
            {code:c}
            SQLPrepare(hStmt, "UPDATE table_name SET a = ? WHERE (id = ?)")
            timestamp.year = 2039;
            timestamp.month = 12;
            timestamp.day = 26;
            timestamp.hour = 0;
            timestamp.minute = 0;
            timestamp.second = 0;
            timestamp.fraction = 100;
            SQLLEN timestamp_len = sizeof(timestamp);
            SQLBindParameter(hStmt, ++paramNum, SQL_PARAM_INPUT, SQL_C_TYPE_TIMESTAMP, SQL_TYPE_TIMESTAMP, 27, 0, &timestamp, 0, &timestamp_len);

            SQLINTEGER sqlint = 1;
            SQLLEN int_len = sizeof(sqlint);
            SQLBindParameter(hStmt, ++paramNum, SQL_PARAM_INPUT, SQL_C_SLONG, SQL_INTEGER, 0, 0, &sqlint, 0, &int_len);

            SQLExecute(hStmt)
            {code}

            If you want to use the reproducer program, it can be compiled with
            {{cl /EHsc /DEBUG:FULL /DUNICODE /D_UNICODE user32.lib odbc32.lib /link /SUBSYSTEM:CONSOLE replicate.cpp}}
            and run with
            {{replicate.exe "DSN=DebugMDB; Uid=root; Pwd="}}

            I wanted to write a test but could not reproduce this with prepared SQL statments like so:

            {code:SQL}
            CREATE DATABASE IF NOT EXISTS `test` CHARACTER SET utf8 COLLATE utf8_bin;
            USE test;

            CREATE OR REPLACE TABLE t1 (id INTEGER, a DateTime, b Timestamp);
            INSERT INTO t1 (id,a,b) VALUES(1, NULL, NULL);
            -- SET SESSION debug_dbug = 'd,enter,exit,error,warning,info,loop:t:F:L:O,data/log.trace';
            PREPARE stmt FROM 'UPDATE t1 SET a = ? WHERE (id = ?)';
            set @a=TIMESTAMP'2039-12-26 00:00:00', @b=1;
            execute stmt using @a,@b;
            -- SET SESSION debug_dbug = '';
            SELECT * FROM t1;
            DROP TABLE t1;
            DEALLOCATE PREPARE stmt;

            id|a |b |
            --|-------------------|-------------------|
             1|2039-12-26 00:00:00|2020-06-10 07:09:16|
            {code}
            mwax Michael Walloch (Inactive) made changes -
            Description We were upgrading to 10.4.12 recently and found an year 2038 issue in the integration tests.
            First, let me state that I already bisected the commit that introduced the changed behaviour which is:
            https://github.com/MariaDB/server/commit/34eb98387f
            MDEV-13995

            I changed a MSDN example to do the following
            Steps to reproduce:
            Setup
            {code:SQL}
            CREATE DATABASE IF NOT EXISTS `test` CHARACTER SET utf8 COLLATE utf8_bin;
            USE test;

            CREATE OR REPLACE TABLE table_name (id INTEGER, a DateTime(3), b Timestamp(3));
            INSERT INTO table_name (id,a,b) VALUES(1, NULL, NULL);
            {code}

            This is working ([^log_direct.trace] is the corresponding dbuglog):
            {code:SQL}
            UPDATE table_name SET a = TIMESTAMP'2039-12-26 00:00:00' WHERE (id = 1)
            {code}

            This is will set NULL for timestamps affected by the year 2038 issue ( [^log_prepared.trace] is the corresponding dbug log)
            (pseudocode, the complete code will be in the reproducer):
            {code:c}
            SQLPrepare(hStmt, "UPDATE table_name SET a = ? WHERE (id = ?)")
            timestamp.year = 2039;
            timestamp.month = 12;
            timestamp.day = 26;
            timestamp.hour = 0;
            timestamp.minute = 0;
            timestamp.second = 0;
            timestamp.fraction = 100;
            SQLLEN timestamp_len = sizeof(timestamp);
            SQLBindParameter(hStmt, ++paramNum, SQL_PARAM_INPUT, SQL_C_TYPE_TIMESTAMP, SQL_TYPE_TIMESTAMP, 27, 0, &timestamp, 0, &timestamp_len);

            SQLINTEGER sqlint = 1;
            SQLLEN int_len = sizeof(sqlint);
            SQLBindParameter(hStmt, ++paramNum, SQL_PARAM_INPUT, SQL_C_SLONG, SQL_INTEGER, 0, 0, &sqlint, 0, &int_len);

            SQLExecute(hStmt)
            {code}

            If you want to use the reproducer program, it can be compiled with
            {{cl /EHsc /DEBUG:FULL /DUNICODE /D_UNICODE user32.lib odbc32.lib /link /SUBSYSTEM:CONSOLE replicate.cpp}}
            and run with
            {{replicate.exe "DSN=DebugMDB; Uid=root; Pwd="}}

            I wanted to write a test but could not reproduce this with prepared SQL statments like so:

            {code:SQL}
            CREATE DATABASE IF NOT EXISTS `test` CHARACTER SET utf8 COLLATE utf8_bin;
            USE test;

            CREATE OR REPLACE TABLE t1 (id INTEGER, a DateTime, b Timestamp);
            INSERT INTO t1 (id,a,b) VALUES(1, NULL, NULL);
            -- SET SESSION debug_dbug = 'd,enter,exit,error,warning,info,loop:t:F:L:O,data/log.trace';
            PREPARE stmt FROM 'UPDATE t1 SET a = ? WHERE (id = ?)';
            set @a=TIMESTAMP'2039-12-26 00:00:00', @b=1;
            execute stmt using @a,@b;
            -- SET SESSION debug_dbug = '';
            SELECT * FROM t1;
            DROP TABLE t1;
            DEALLOCATE PREPARE stmt;

            id|a |b |
            --|-------------------|-------------------|
             1|2039-12-26 00:00:00|2020-06-10 07:09:16|
            {code}             		We were upgrading to 10.4.12 recently and found an year 2038 issue in the integration tests.
            First, let me state that I already bisected the commit that introduced the changed behaviour which is:
            https://github.com/MariaDB/server/commit/34eb98387f
            MDEV-13995

            I changed a MSDN example to do the following
            Steps to reproduce:
            Setup
            {code:SQL}
            CREATE DATABASE IF NOT EXISTS `test` CHARACTER SET utf8 COLLATE utf8_bin;
            USE test;

            CREATE OR REPLACE TABLE table_name (id INTEGER, a DateTime(3), b Timestamp(3));
            INSERT INTO table_name (id,a,b) VALUES(1, NULL, NULL);
            {code}

            This is working ([^log_direct.trace] is the corresponding dbuglog):
            {code:SQL}
            UPDATE table_name SET a = TIMESTAMP'2039-12-26 00:00:00' WHERE (id = 1)
            {code}

            Result:
            {code:SQL}
            id|a |b |
            --|-------------------|-------------------|
             1|2039-12-26 00:00:00|2020-06-10 07:12:11|
            {code}

            This is will set NULL for timestamps affected by the year 2038 issue ( [^log_prepared.trace] is the corresponding dbug log)
            (pseudocode, the complete code will be in the reproducer):
            {code:c}
            SQLPrepare(hStmt, "UPDATE table_name SET a = ? WHERE (id = ?)")
            timestamp.year = 2039;
            timestamp.month = 12;
            timestamp.day = 26;
            timestamp.hour = 0;
            timestamp.minute = 0;
            timestamp.second = 0;
            timestamp.fraction = 100;
            SQLLEN timestamp_len = sizeof(timestamp);
            SQLBindParameter(hStmt, ++paramNum, SQL_PARAM_INPUT, SQL_C_TYPE_TIMESTAMP, SQL_TYPE_TIMESTAMP, 27, 0, &timestamp, 0, &timestamp_len);

            SQLINTEGER sqlint = 1;
            SQLLEN int_len = sizeof(sqlint);
            SQLBindParameter(hStmt, ++paramNum, SQL_PARAM_INPUT, SQL_C_SLONG, SQL_INTEGER, 0, 0, &sqlint, 0, &int_len);

            SQLExecute(hStmt)
            {code}

            Result:
            {code:SQL}
            | id | a | b |
            | 1 | <NULL> | 2020-06-09 13:28:17.098 |
            {code}

            If you want to use the reproducer program, it can be compiled with
            {{cl /EHsc /DEBUG:FULL /DUNICODE /D_UNICODE user32.lib odbc32.lib /link /SUBSYSTEM:CONSOLE replicate.cpp}}
            and run with
            {{replicate.exe "DSN=DebugMDB; Uid=root; Pwd="}}

            I wanted to write a test but could not reproduce this with prepared SQL statments like so:

            {code:SQL}
            CREATE DATABASE IF NOT EXISTS `test` CHARACTER SET utf8 COLLATE utf8_bin;
            USE test;

            CREATE OR REPLACE TABLE t1 (id INTEGER, a DateTime, b Timestamp);
            INSERT INTO t1 (id,a,b) VALUES(1, NULL, NULL);
            -- SET SESSION debug_dbug = 'd,enter,exit,error,warning,info,loop:t:F:L:O,data/log.trace';
            PREPARE stmt FROM 'UPDATE t1 SET a = ? WHERE (id = ?)';
            set @a=TIMESTAMP'2039-12-26 00:00:00', @b=1;
            execute stmt using @a,@b;
            -- SET SESSION debug_dbug = '';
            SELECT * FROM t1;
            DROP TABLE t1;
            DEALLOCATE PREPARE stmt;
            {code}

            Result:
            {code:SQL}
            id|a |b |
            --|-------------------|-------------------|
             1|2039-12-26 00:00:00|2020-06-10 07:09:16|
            {code}
            mwax Michael Walloch (Inactive) made changes -
            Description We were upgrading to 10.4.12 recently and found an year 2038 issue in the integration tests.
            First, let me state that I already bisected the commit that introduced the changed behaviour which is:
            https://github.com/MariaDB/server/commit/34eb98387f
            MDEV-13995

            I changed a MSDN example to do the following
            Steps to reproduce:
            Setup
            {code:SQL}
            CREATE DATABASE IF NOT EXISTS `test` CHARACTER SET utf8 COLLATE utf8_bin;
            USE test;

            CREATE OR REPLACE TABLE table_name (id INTEGER, a DateTime(3), b Timestamp(3));
            INSERT INTO table_name (id,a,b) VALUES(1, NULL, NULL);
            {code}

            This is working ([^log_direct.trace] is the corresponding dbuglog):
            {code:SQL}
            UPDATE table_name SET a = TIMESTAMP'2039-12-26 00:00:00' WHERE (id = 1)
            {code}

            Result:
            {code:SQL}
            id|a |b |
            --|-------------------|-------------------|
             1|2039-12-26 00:00:00|2020-06-10 07:12:11|
            {code}

            This is will set NULL for timestamps affected by the year 2038 issue ( [^log_prepared.trace] is the corresponding dbug log)
            (pseudocode, the complete code will be in the reproducer):
            {code:c}
            SQLPrepare(hStmt, "UPDATE table_name SET a = ? WHERE (id = ?)")
            timestamp.year = 2039;
            timestamp.month = 12;
            timestamp.day = 26;
            timestamp.hour = 0;
            timestamp.minute = 0;
            timestamp.second = 0;
            timestamp.fraction = 100;
            SQLLEN timestamp_len = sizeof(timestamp);
            SQLBindParameter(hStmt, ++paramNum, SQL_PARAM_INPUT, SQL_C_TYPE_TIMESTAMP, SQL_TYPE_TIMESTAMP, 27, 0, &timestamp, 0, &timestamp_len);

            SQLINTEGER sqlint = 1;
            SQLLEN int_len = sizeof(sqlint);
            SQLBindParameter(hStmt, ++paramNum, SQL_PARAM_INPUT, SQL_C_SLONG, SQL_INTEGER, 0, 0, &sqlint, 0, &int_len);

            SQLExecute(hStmt)
            {code}

            Result:
            {code:SQL}
            | id | a | b |
            | 1 | <NULL> | 2020-06-09 13:28:17.098 |
            {code}

            If you want to use the reproducer program, it can be compiled with
            {{cl /EHsc /DEBUG:FULL /DUNICODE /D_UNICODE user32.lib odbc32.lib /link /SUBSYSTEM:CONSOLE replicate.cpp}}
            and run with
            {{replicate.exe "DSN=DebugMDB; Uid=root; Pwd="}}

            I wanted to write a test but could not reproduce this with prepared SQL statments like so:

            {code:SQL}
            CREATE DATABASE IF NOT EXISTS `test` CHARACTER SET utf8 COLLATE utf8_bin;
            USE test;

            CREATE OR REPLACE TABLE t1 (id INTEGER, a DateTime, b Timestamp);
            INSERT INTO t1 (id,a,b) VALUES(1, NULL, NULL);
            -- SET SESSION debug_dbug = 'd,enter,exit,error,warning,info,loop:t:F:L:O,data/log.trace';
            PREPARE stmt FROM 'UPDATE t1 SET a = ? WHERE (id = ?)';
            set @a=TIMESTAMP'2039-12-26 00:00:00', @b=1;
            execute stmt using @a,@b;
            -- SET SESSION debug_dbug = '';
            SELECT * FROM t1;
            DROP TABLE t1;
            DEALLOCATE PREPARE stmt;
            {code}

            Result:
            {code:SQL}
            id|a |b |
            --|-------------------|-------------------|
             1|2039-12-26 00:00:00|2020-06-10 07:09:16|
            {code}             		We were upgrading to 10.4.12 recently and found an year 2038 issue in the integration tests.
            This is a regression from 10.4.0 and earlier versions.
            First, let me state that I already bisected the commit that introduced the changed behaviour which is:
            https://github.com/MariaDB/server/commit/34eb98387f
            MDEV-13995

            I changed a MSDN example to do the following
            Steps to reproduce:
            Setup
            {code:SQL}
            CREATE DATABASE IF NOT EXISTS `test` CHARACTER SET utf8 COLLATE utf8_bin;
            USE test;

            CREATE OR REPLACE TABLE table_name (id INTEGER, a DateTime(3), b Timestamp(3));
            INSERT INTO table_name (id,a,b) VALUES(1, NULL, NULL);
            {code}

            This is working ([^log_direct.trace] is the corresponding dbuglog):
            {code:SQL}
            UPDATE table_name SET a = TIMESTAMP'2039-12-26 00:00:00' WHERE (id = 1)
            {code}

            Result:
            {code:SQL}
            id|a |b |
            --|-------------------|-------------------|
             1|2039-12-26 00:00:00|2020-06-10 07:12:11|
            {code}

            This is will set NULL for timestamps affected by the year 2038 issue ( [^log_prepared.trace] is the corresponding dbug log)
            (pseudocode, the complete code will be in the reproducer):
            {code:c}
            SQLPrepare(hStmt, "UPDATE table_name SET a = ? WHERE (id = ?)")
            timestamp.year = 2039;
            timestamp.month = 12;
            timestamp.day = 26;
            timestamp.hour = 0;
            timestamp.minute = 0;
            timestamp.second = 0;
            timestamp.fraction = 100;
            SQLLEN timestamp_len = sizeof(timestamp);
            SQLBindParameter(hStmt, ++paramNum, SQL_PARAM_INPUT, SQL_C_TYPE_TIMESTAMP, SQL_TYPE_TIMESTAMP, 27, 0, &timestamp, 0, &timestamp_len);

            SQLINTEGER sqlint = 1;
            SQLLEN int_len = sizeof(sqlint);
            SQLBindParameter(hStmt, ++paramNum, SQL_PARAM_INPUT, SQL_C_SLONG, SQL_INTEGER, 0, 0, &sqlint, 0, &int_len);

            SQLExecute(hStmt)
            {code}

            Result:
            {code:SQL}
            | id | a | b |
            | 1 | <NULL> | 2020-06-09 13:28:17.098 |
            {code}

            If you want to use the reproducer program, it can be compiled with
            {{cl /EHsc /DEBUG:FULL /DUNICODE /D_UNICODE user32.lib odbc32.lib /link /SUBSYSTEM:CONSOLE replicate.cpp}}
            and run with
            {{replicate.exe "DSN=DebugMDB; Uid=root; Pwd="}}

            I wanted to write a test but could not reproduce this with prepared SQL statments like so:

            {code:SQL}
            CREATE DATABASE IF NOT EXISTS `test` CHARACTER SET utf8 COLLATE utf8_bin;
            USE test;

            CREATE OR REPLACE TABLE t1 (id INTEGER, a DateTime, b Timestamp);
            INSERT INTO t1 (id,a,b) VALUES(1, NULL, NULL);
            -- SET SESSION debug_dbug = 'd,enter,exit,error,warning,info,loop:t:F:L:O,data/log.trace';
            PREPARE stmt FROM 'UPDATE t1 SET a = ? WHERE (id = ?)';
            set @a=TIMESTAMP'2039-12-26 00:00:00', @b=1;
            execute stmt using @a,@b;
            -- SET SESSION debug_dbug = '';
            SELECT * FROM t1;
            DROP TABLE t1;
            DEALLOCATE PREPARE stmt;
            {code}

            Result:
            {code:SQL}
            id|a |b |
            --|-------------------|-------------------|
             1|2039-12-26 00:00:00|2020-06-10 07:09:16|
            {code}
            mwax Michael Walloch (Inactive) made changes -
            Labels regression
            mwax Michael Walloch (Inactive) made changes -
            Description We were upgrading to 10.4.12 recently and found an year 2038 issue in the integration tests.
            This is a regression from 10.4.0 and earlier versions.
            First, let me state that I already bisected the commit that introduced the changed behaviour which is:
            https://github.com/MariaDB/server/commit/34eb98387f
            MDEV-13995

            I changed a MSDN example to do the following
            Steps to reproduce:
            Setup
            {code:SQL}
            CREATE DATABASE IF NOT EXISTS `test` CHARACTER SET utf8 COLLATE utf8_bin;
            USE test;

            CREATE OR REPLACE TABLE table_name (id INTEGER, a DateTime(3), b Timestamp(3));
            INSERT INTO table_name (id,a,b) VALUES(1, NULL, NULL);
            {code}

            This is working ([^log_direct.trace] is the corresponding dbuglog):
            {code:SQL}
            UPDATE table_name SET a = TIMESTAMP'2039-12-26 00:00:00' WHERE (id = 1)
            {code}

            Result:
            {code:SQL}
            id|a |b |
            --|-------------------|-------------------|
             1|2039-12-26 00:00:00|2020-06-10 07:12:11|
            {code}

            This is will set NULL for timestamps affected by the year 2038 issue ( [^log_prepared.trace] is the corresponding dbug log)
            (pseudocode, the complete code will be in the reproducer):
            {code:c}
            SQLPrepare(hStmt, "UPDATE table_name SET a = ? WHERE (id = ?)")
            timestamp.year = 2039;
            timestamp.month = 12;
            timestamp.day = 26;
            timestamp.hour = 0;
            timestamp.minute = 0;
            timestamp.second = 0;
            timestamp.fraction = 100;
            SQLLEN timestamp_len = sizeof(timestamp);
            SQLBindParameter(hStmt, ++paramNum, SQL_PARAM_INPUT, SQL_C_TYPE_TIMESTAMP, SQL_TYPE_TIMESTAMP, 27, 0, &timestamp, 0, &timestamp_len);

            SQLINTEGER sqlint = 1;
            SQLLEN int_len = sizeof(sqlint);
            SQLBindParameter(hStmt, ++paramNum, SQL_PARAM_INPUT, SQL_C_SLONG, SQL_INTEGER, 0, 0, &sqlint, 0, &int_len);

            SQLExecute(hStmt)
            {code}

            Result:
            {code:SQL}
            | id | a | b |
            | 1 | <NULL> | 2020-06-09 13:28:17.098 |
            {code}

            If you want to use the reproducer program, it can be compiled with
            {{cl /EHsc /DEBUG:FULL /DUNICODE /D_UNICODE user32.lib odbc32.lib /link /SUBSYSTEM:CONSOLE replicate.cpp}}
            and run with
            {{replicate.exe "DSN=DebugMDB; Uid=root; Pwd="}}

            I wanted to write a test but could not reproduce this with prepared SQL statments like so:

            {code:SQL}
            CREATE DATABASE IF NOT EXISTS `test` CHARACTER SET utf8 COLLATE utf8_bin;
            USE test;

            CREATE OR REPLACE TABLE t1 (id INTEGER, a DateTime, b Timestamp);
            INSERT INTO t1 (id,a,b) VALUES(1, NULL, NULL);
            -- SET SESSION debug_dbug = 'd,enter,exit,error,warning,info,loop:t:F:L:O,data/log.trace';
            PREPARE stmt FROM 'UPDATE t1 SET a = ? WHERE (id = ?)';
            set @a=TIMESTAMP'2039-12-26 00:00:00', @b=1;
            execute stmt using @a,@b;
            -- SET SESSION debug_dbug = '';
            SELECT * FROM t1;
            DROP TABLE t1;
            DEALLOCATE PREPARE stmt;
            {code}

            Result:
            {code:SQL}
            id|a |b |
            --|-------------------|-------------------|
             1|2039-12-26 00:00:00|2020-06-10 07:09:16|
            {code}             		We were upgrading to 10.4.12 recently and found an year 2038 issue in the integration tests.
            This is a regression from 10.4.0 and earlier versions.
            First, let me state that I already bisected the commit that introduced the changed behaviour which is:
            https://github.com/MariaDB/server/commit/34eb98387f
            MDEV-13995
            Probably the best to look at this would be @Alexander Barkov

            I changed a MSDN example to do the following
            Steps to reproduce:
            Setup
            {code:SQL}
            CREATE DATABASE IF NOT EXISTS `test` CHARACTER SET utf8 COLLATE utf8_bin;
            USE test;

            CREATE OR REPLACE TABLE table_name (id INTEGER, a DateTime(3), b Timestamp(3));
            INSERT INTO table_name (id,a,b) VALUES(1, NULL, NULL);
            {code}

            This is working ([^log_direct.trace] is the corresponding dbuglog):
            {code:SQL}
            UPDATE table_name SET a = TIMESTAMP'2039-12-26 00:00:00' WHERE (id = 1)
            {code}

            Result:
            {code:SQL}
            id|a |b |
            --|-------------------|-------------------|
             1|2039-12-26 00:00:00|2020-06-10 07:12:11|
            {code}

            This is will set NULL for timestamps affected by the year 2038 issue ( [^log_prepared.trace] is the corresponding dbug log)
            (pseudocode, the complete code will be in the reproducer):
            {code:c}
            SQLPrepare(hStmt, "UPDATE table_name SET a = ? WHERE (id = ?)")
            timestamp.year = 2039;
            timestamp.month = 12;
            timestamp.day = 26;
            timestamp.hour = 0;
            timestamp.minute = 0;
            timestamp.second = 0;
            timestamp.fraction = 100;
            SQLLEN timestamp_len = sizeof(timestamp);
            SQLBindParameter(hStmt, ++paramNum, SQL_PARAM_INPUT, SQL_C_TYPE_TIMESTAMP, SQL_TYPE_TIMESTAMP, 27, 0, &timestamp, 0, &timestamp_len);

            SQLINTEGER sqlint = 1;
            SQLLEN int_len = sizeof(sqlint);
            SQLBindParameter(hStmt, ++paramNum, SQL_PARAM_INPUT, SQL_C_SLONG, SQL_INTEGER, 0, 0, &sqlint, 0, &int_len);

            SQLExecute(hStmt)
            {code}

            Result:
            {code:SQL}
            | id | a | b |
            | 1 | <NULL> | 2020-06-09 13:28:17.098 |
            {code}

            If you want to use the reproducer program, it can be compiled with
            {{cl /EHsc /DEBUG:FULL /DUNICODE /D_UNICODE user32.lib odbc32.lib /link /SUBSYSTEM:CONSOLE replicate.cpp}}
            and run with
            {{replicate.exe "DSN=DebugMDB; Uid=root; Pwd="}}

            I wanted to write a test but could not reproduce this with prepared SQL statments like so:

            {code:SQL}
            CREATE DATABASE IF NOT EXISTS `test` CHARACTER SET utf8 COLLATE utf8_bin;
            USE test;

            CREATE OR REPLACE TABLE t1 (id INTEGER, a DateTime, b Timestamp);
            INSERT INTO t1 (id,a,b) VALUES(1, NULL, NULL);
            -- SET SESSION debug_dbug = 'd,enter,exit,error,warning,info,loop:t:F:L:O,data/log.trace';
            PREPARE stmt FROM 'UPDATE t1 SET a = ? WHERE (id = ?)';
            set @a=TIMESTAMP'2039-12-26 00:00:00', @b=1;
            execute stmt using @a,@b;
            -- SET SESSION debug_dbug = '';
            SELECT * FROM t1;
            DROP TABLE t1;
            DEALLOCATE PREPARE stmt;
            {code}

            Result:
            {code:SQL}
            id|a |b |
            --|-------------------|-------------------|
             1|2039-12-26 00:00:00|2020-06-10 07:09:16|
            {code}
            mwax Michael Walloch (Inactive) made changes -
            Description We were upgrading to 10.4.12 recently and found an year 2038 issue in the integration tests.
            This is a regression from 10.4.0 and earlier versions.
            First, let me state that I already bisected the commit that introduced the changed behaviour which is:
            https://github.com/MariaDB/server/commit/34eb98387f
            MDEV-13995
            Probably the best to look at this would be @Alexander Barkov

            I changed a MSDN example to do the following
            Steps to reproduce:
            Setup
            {code:SQL}
            CREATE DATABASE IF NOT EXISTS `test` CHARACTER SET utf8 COLLATE utf8_bin;
            USE test;

            CREATE OR REPLACE TABLE table_name (id INTEGER, a DateTime(3), b Timestamp(3));
            INSERT INTO table_name (id,a,b) VALUES(1, NULL, NULL);
            {code}

            This is working ([^log_direct.trace] is the corresponding dbuglog):
            {code:SQL}
            UPDATE table_name SET a = TIMESTAMP'2039-12-26 00:00:00' WHERE (id = 1)
            {code}

            Result:
            {code:SQL}
            id|a |b |
            --|-------------------|-------------------|
             1|2039-12-26 00:00:00|2020-06-10 07:12:11|
            {code}

            This is will set NULL for timestamps affected by the year 2038 issue ( [^log_prepared.trace] is the corresponding dbug log)
            (pseudocode, the complete code will be in the reproducer):
            {code:c}
            SQLPrepare(hStmt, "UPDATE table_name SET a = ? WHERE (id = ?)")
            timestamp.year = 2039;
            timestamp.month = 12;
            timestamp.day = 26;
            timestamp.hour = 0;
            timestamp.minute = 0;
            timestamp.second = 0;
            timestamp.fraction = 100;
            SQLLEN timestamp_len = sizeof(timestamp);
            SQLBindParameter(hStmt, ++paramNum, SQL_PARAM_INPUT, SQL_C_TYPE_TIMESTAMP, SQL_TYPE_TIMESTAMP, 27, 0, &timestamp, 0, &timestamp_len);

            SQLINTEGER sqlint = 1;
            SQLLEN int_len = sizeof(sqlint);
            SQLBindParameter(hStmt, ++paramNum, SQL_PARAM_INPUT, SQL_C_SLONG, SQL_INTEGER, 0, 0, &sqlint, 0, &int_len);

            SQLExecute(hStmt)
            {code}

            Result:
            {code:SQL}
            | id | a | b |
            | 1 | <NULL> | 2020-06-09 13:28:17.098 |
            {code}

            If you want to use the reproducer program, it can be compiled with
            {{cl /EHsc /DEBUG:FULL /DUNICODE /D_UNICODE user32.lib odbc32.lib /link /SUBSYSTEM:CONSOLE replicate.cpp}}
            and run with
            {{replicate.exe "DSN=DebugMDB; Uid=root; Pwd="}}

            I wanted to write a test but could not reproduce this with prepared SQL statments like so:

            {code:SQL}
            CREATE DATABASE IF NOT EXISTS `test` CHARACTER SET utf8 COLLATE utf8_bin;
            USE test;

            CREATE OR REPLACE TABLE t1 (id INTEGER, a DateTime, b Timestamp);
            INSERT INTO t1 (id,a,b) VALUES(1, NULL, NULL);
            -- SET SESSION debug_dbug = 'd,enter,exit,error,warning,info,loop:t:F:L:O,data/log.trace';
            PREPARE stmt FROM 'UPDATE t1 SET a = ? WHERE (id = ?)';
            set @a=TIMESTAMP'2039-12-26 00:00:00', @b=1;
            execute stmt using @a,@b;
            -- SET SESSION debug_dbug = '';
            SELECT * FROM t1;
            DROP TABLE t1;
            DEALLOCATE PREPARE stmt;
            {code}

            Result:
            {code:SQL}
            id|a |b |
            --|-------------------|-------------------|
             1|2039-12-26 00:00:00|2020-06-10 07:09:16|
            {code}             		We were upgrading to 10.4.12 recently and found an year 2038 issue in the integration tests.
            This is a regression from 10.4.0 and earlier versions.
            First, let me state that I already bisected the commit that introduced the changed behaviour which is:
            https://github.com/MariaDB/server/commit/34eb98387f
            MDEV-13995
            Probably the best to look at this would be @"Alexander Barkov"

            I changed a MSDN example to do the following
            Steps to reproduce:
            Setup
            {code:SQL}
            CREATE DATABASE IF NOT EXISTS `test` CHARACTER SET utf8 COLLATE utf8_bin;
            USE test;

            CREATE OR REPLACE TABLE table_name (id INTEGER, a DateTime(3), b Timestamp(3));
            INSERT INTO table_name (id,a,b) VALUES(1, NULL, NULL);
            {code}

            This is working ([^log_direct.trace] is the corresponding dbuglog):
            {code:SQL}
            UPDATE table_name SET a = TIMESTAMP'2039-12-26 00:00:00' WHERE (id = 1)
            {code}

            Result:
            {code:SQL}
            id|a |b |
            --|-------------------|-------------------|
             1|2039-12-26 00:00:00|2020-06-10 07:12:11|
            {code}

            This is will set NULL for timestamps affected by the year 2038 issue ( [^log_prepared.trace] is the corresponding dbug log)
            (pseudocode, the complete code will be in the reproducer):
            {code:c}
            SQLPrepare(hStmt, "UPDATE table_name SET a = ? WHERE (id = ?)")
            timestamp.year = 2039;
            timestamp.month = 12;
            timestamp.day = 26;
            timestamp.hour = 0;
            timestamp.minute = 0;
            timestamp.second = 0;
            timestamp.fraction = 100;
            SQLLEN timestamp_len = sizeof(timestamp);
            SQLBindParameter(hStmt, ++paramNum, SQL_PARAM_INPUT, SQL_C_TYPE_TIMESTAMP, SQL_TYPE_TIMESTAMP, 27, 0, &timestamp, 0, &timestamp_len);

            SQLINTEGER sqlint = 1;
            SQLLEN int_len = sizeof(sqlint);
            SQLBindParameter(hStmt, ++paramNum, SQL_PARAM_INPUT, SQL_C_SLONG, SQL_INTEGER, 0, 0, &sqlint, 0, &int_len);

            SQLExecute(hStmt)
            {code}

            Result:
            {code:SQL}
            | id | a | b |
            | 1 | <NULL> | 2020-06-09 13:28:17.098 |
            {code}

            If you want to use the reproducer program, it can be compiled with
            {{cl /EHsc /DEBUG:FULL /DUNICODE /D_UNICODE user32.lib odbc32.lib /link /SUBSYSTEM:CONSOLE replicate.cpp}}
            and run with
            {{replicate.exe "DSN=DebugMDB; Uid=root; Pwd="}}

            I wanted to write a test but could not reproduce this with prepared SQL statments like so:

            {code:SQL}
            CREATE DATABASE IF NOT EXISTS `test` CHARACTER SET utf8 COLLATE utf8_bin;
            USE test;

            CREATE OR REPLACE TABLE t1 (id INTEGER, a DateTime, b Timestamp);
            INSERT INTO t1 (id,a,b) VALUES(1, NULL, NULL);
            -- SET SESSION debug_dbug = 'd,enter,exit,error,warning,info,loop:t:F:L:O,data/log.trace';
            PREPARE stmt FROM 'UPDATE t1 SET a = ? WHERE (id = ?)';
            set @a=TIMESTAMP'2039-12-26 00:00:00', @b=1;
            execute stmt using @a,@b;
            -- SET SESSION debug_dbug = '';
            SELECT * FROM t1;
            DROP TABLE t1;
            DEALLOCATE PREPARE stmt;
            {code}

            Result:
            {code:SQL}
            id|a |b |
            --|-------------------|-------------------|
             1|2039-12-26 00:00:00|2020-06-10 07:09:16|
            {code}
            mwax Michael Walloch (Inactive) made changes -
            mwax Michael Walloch (Inactive) made changes -
            Comment [ @mwax ]
            mwax Michael Walloch (Inactive) made changes -
            Comment [ @bar ]
            mwax Michael Walloch (Inactive) made changes -
            Description We were upgrading to 10.4.12 recently and found an year 2038 issue in the integration tests.
            This is a regression from 10.4.0 and earlier versions.
            First, let me state that I already bisected the commit that introduced the changed behaviour which is:
            https://github.com/MariaDB/server/commit/34eb98387f
            MDEV-13995
            Probably the best to look at this would be @"Alexander Barkov"

            I changed a MSDN example to do the following
            Steps to reproduce:
            Setup
            {code:SQL}
            CREATE DATABASE IF NOT EXISTS `test` CHARACTER SET utf8 COLLATE utf8_bin;
            USE test;

            CREATE OR REPLACE TABLE table_name (id INTEGER, a DateTime(3), b Timestamp(3));
            INSERT INTO table_name (id,a,b) VALUES(1, NULL, NULL);
            {code}

            This is working ([^log_direct.trace] is the corresponding dbuglog):
            {code:SQL}
            UPDATE table_name SET a = TIMESTAMP'2039-12-26 00:00:00' WHERE (id = 1)
            {code}

            Result:
            {code:SQL}
            id|a |b |
            --|-------------------|-------------------|
             1|2039-12-26 00:00:00|2020-06-10 07:12:11|
            {code}

            This is will set NULL for timestamps affected by the year 2038 issue ( [^log_prepared.trace] is the corresponding dbug log)
            (pseudocode, the complete code will be in the reproducer):
            {code:c}
            SQLPrepare(hStmt, "UPDATE table_name SET a = ? WHERE (id = ?)")
            timestamp.year = 2039;
            timestamp.month = 12;
            timestamp.day = 26;
            timestamp.hour = 0;
            timestamp.minute = 0;
            timestamp.second = 0;
            timestamp.fraction = 100;
            SQLLEN timestamp_len = sizeof(timestamp);
            SQLBindParameter(hStmt, ++paramNum, SQL_PARAM_INPUT, SQL_C_TYPE_TIMESTAMP, SQL_TYPE_TIMESTAMP, 27, 0, &timestamp, 0, &timestamp_len);

            SQLINTEGER sqlint = 1;
            SQLLEN int_len = sizeof(sqlint);
            SQLBindParameter(hStmt, ++paramNum, SQL_PARAM_INPUT, SQL_C_SLONG, SQL_INTEGER, 0, 0, &sqlint, 0, &int_len);

            SQLExecute(hStmt)
            {code}

            Result:
            {code:SQL}
            | id | a | b |
            | 1 | <NULL> | 2020-06-09 13:28:17.098 |
            {code}

            If you want to use the reproducer program, it can be compiled with
            {{cl /EHsc /DEBUG:FULL /DUNICODE /D_UNICODE user32.lib odbc32.lib /link /SUBSYSTEM:CONSOLE replicate.cpp}}
            and run with
            {{replicate.exe "DSN=DebugMDB; Uid=root; Pwd="}}

            I wanted to write a test but could not reproduce this with prepared SQL statments like so:

            {code:SQL}
            CREATE DATABASE IF NOT EXISTS `test` CHARACTER SET utf8 COLLATE utf8_bin;
            USE test;

            CREATE OR REPLACE TABLE t1 (id INTEGER, a DateTime, b Timestamp);
            INSERT INTO t1 (id,a,b) VALUES(1, NULL, NULL);
            -- SET SESSION debug_dbug = 'd,enter,exit,error,warning,info,loop:t:F:L:O,data/log.trace';
            PREPARE stmt FROM 'UPDATE t1 SET a = ? WHERE (id = ?)';
            set @a=TIMESTAMP'2039-12-26 00:00:00', @b=1;
            execute stmt using @a,@b;
            -- SET SESSION debug_dbug = '';
            SELECT * FROM t1;
            DROP TABLE t1;
            DEALLOCATE PREPARE stmt;
            {code}

            Result:
            {code:SQL}
            id|a |b |
            --|-------------------|-------------------|
             1|2039-12-26 00:00:00|2020-06-10 07:09:16|
            {code}             		We were upgrading to 10.4.12 recently and found an year 2038 issue in the integration tests.
            This is a regression from 10.4.0 which is known good.
            First, let me state that I already bisected the commit that introduced the changed behaviour which is:
            https://github.com/MariaDB/server/commit/34eb98387f
            MDEV-13995
            Probably the best to look at this would be @"Alexander Barkov"

            I changed a MSDN example to do the following
            Steps to reproduce:
            Setup
            {code:SQL}
            CREATE DATABASE IF NOT EXISTS `test` CHARACTER SET utf8 COLLATE utf8_bin;
            USE test;

            CREATE OR REPLACE TABLE table_name (id INTEGER, a DateTime(3), b Timestamp(3));
            INSERT INTO table_name (id,a,b) VALUES(1, NULL, NULL);
            {code}

            This is working ([^log_direct.trace] is the corresponding dbuglog):
            {code:SQL}
            UPDATE table_name SET a = TIMESTAMP'2039-12-26 00:00:00' WHERE (id = 1)
            {code}

            Result:
            {code:SQL}
            id|a |b |
            --|-------------------|-------------------|
             1|2039-12-26 00:00:00|2020-06-10 07:12:11|
            {code}

            This is will set NULL for timestamps affected by the year 2038 issue ( [^log_prepared.trace] is the corresponding dbug log)
            (pseudocode, the complete code will be in the reproducer):
            {code:c}
            SQLPrepare(hStmt, "UPDATE table_name SET a = ? WHERE (id = ?)")
            timestamp.year = 2039;
            timestamp.month = 12;
            timestamp.day = 26;
            timestamp.hour = 0;
            timestamp.minute = 0;
            timestamp.second = 0;
            timestamp.fraction = 100;
            SQLLEN timestamp_len = sizeof(timestamp);
            SQLBindParameter(hStmt, ++paramNum, SQL_PARAM_INPUT, SQL_C_TYPE_TIMESTAMP, SQL_TYPE_TIMESTAMP, 27, 0, &timestamp, 0, &timestamp_len);

            SQLINTEGER sqlint = 1;
            SQLLEN int_len = sizeof(sqlint);
            SQLBindParameter(hStmt, ++paramNum, SQL_PARAM_INPUT, SQL_C_SLONG, SQL_INTEGER, 0, 0, &sqlint, 0, &int_len);

            SQLExecute(hStmt)
            {code}

            Result:
            {code:SQL}
            | id | a | b |
            | 1 | <NULL> | 2020-06-09 13:28:17.098 |
            {code}

            If you want to use the reproducer program, it can be compiled with
            {{cl /EHsc /DEBUG:FULL /DUNICODE /D_UNICODE user32.lib odbc32.lib /link /SUBSYSTEM:CONSOLE replicate.cpp}}
            and run with
            {{replicate.exe "DSN=DebugMDB; Uid=root; Pwd="}}

            I wanted to write a test but could not reproduce this with prepared SQL statments like so:

            {code:SQL}
            CREATE DATABASE IF NOT EXISTS `test` CHARACTER SET utf8 COLLATE utf8_bin;
            USE test;

            CREATE OR REPLACE TABLE t1 (id INTEGER, a DateTime, b Timestamp);
            INSERT INTO t1 (id,a,b) VALUES(1, NULL, NULL);
            -- SET SESSION debug_dbug = 'd,enter,exit,error,warning,info,loop:t:F:L:O,data/log.trace';
            PREPARE stmt FROM 'UPDATE t1 SET a = ? WHERE (id = ?)';
            set @a=TIMESTAMP'2039-12-26 00:00:00', @b=1;
            execute stmt using @a,@b;
            -- SET SESSION debug_dbug = '';
            SELECT * FROM t1;
            DROP TABLE t1;
            DEALLOCATE PREPARE stmt;
            {code}

            Result:
            {code:SQL}
            id|a |b |
            --|-------------------|-------------------|
             1|2039-12-26 00:00:00|2020-06-10 07:09:16|
            {code}
            mwax Michael Walloch (Inactive) made changes -
            Affects Version/s 10.5 [ 23123 ]
            mwax Michael Walloch (Inactive) made changes -
            Labels regression datatype regression
            elenst Elena Stepanova made changes -
            Fix Version/s 10.4 [ 22408 ]
            Fix Version/s 10.5 [ 23123 ]
            Assignee Alexander Barkov [ bar ]
            serg Sergei Golubchik made changes -
            Workflow MariaDB v3 [ 109774 ] MariaDB v4 [ 142003 ]
            bar Alexander Barkov made changes -
            Attachment replicate-linux.cpp [ 71107 ]
            bar Alexander Barkov made changes -
            Assignee Alexander Barkov [ bar ] Lawrin Novitsky [ lawrin ]
            Lawrin Lawrin Novitsky made changes -
            Component/s General [ 14302 ]
            Component/s Data types [ 13906 ]
            Component/s Temporal Types [ 11000 ]
            Fix Version/s 3.1.15 [ 26802 ]
            Fix Version/s 10.4 [ 22408 ]
            Fix Version/s 10.5 [ 23123 ]
            Key MDEV-22843 ODBC-417
            Affects Version/s 3.1.14 [ 26008 ]
            Affects Version/s 10.5 [ 23123 ]
            Affects Version/s 10.4.1 [ 23228 ]
            Affects Version/s 10.4.12 [ 24019 ]
            Affects Version/s 10.5.3 [ 24263 ]
            Project MariaDB Server [ 10000 ] MariaDB Connector/ODBC [ 10400 ]
            Lawrin Lawrin Novitsky made changes -
            Lawrin Lawrin Novitsky made changes -
            Resolution Duplicate [ 3 ]
            Status Open [ 1 ] Closed [ 6 ]

            People

              Lawrin Lawrin Novitsky
              mwax Michael Walloch (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.