Bug #121728 TIME DEFAULT comparison gives contradictory results in SELECT and WHERE

Description:
On the official MySQL Community Server 26.10.0 binary, with an empty session
sql_mode, the expression DEFAULT(v) < dt returns 0 for every row when evaluated
in the SELECT list, but the same expression in WHERE selects every row.
WHERE NOT(DEFAULT(v) < dt) selects no rows.

The test uses a TIME(6) column with a valid zero-time default and a DATETIME(6)
column with a valid nonzero default. No zero DATE or DATETIME values are inserted.
The inconsistency occurs with an unchanged table in one connection.

Environment: MySQL Community Server - GPL 26.10.0, official
mysql-26.10.0-linux-glibc2.28-x86_64-minimal.tar.xz, deployed using dbdeployer 1.73.0.

How to repeat:
Execute the following in a fresh test database:

    SELECT VERSION(), @@version_comment;
    SET SESSION sql_mode='';
    SET SESSION time_zone='+00:00';

    CREATE TABLE t1 (
      id INT PRIMARY KEY,
      v TIME(6) DEFAULT '00:00:00',
      dt DATETIME(6) DEFAULT '2010-03-04 00:00:00'
    );
    INSERT INTO t1(id) VALUES (1),(2),(3),(4),(5),(6),(7),(8);

    SELECT id, DEFAULT(v), dt, (DEFAULT(v)<dt) AS p
    FROM t1 ORDER BY id;

    SELECT id FROM t1 WHERE DEFAULT(v)<dt ORDER BY id;
    SELECT id FROM t1 WHERE NOT(DEFAULT(v)<dt) ORDER BY id;

Actual results:
- The first SELECT returns ids 1 through 8; p is 0 for every row.
  DEFAULT(v) is 00:00:00.000000 and dt is 2010-03-04 00:00:00.000000.
- The second SELECT nevertheless returns ids 1 through 8.
- The third SELECT returns no rows.

Expected results:
Evaluation of the same comparison should be consistent in the SELECT list and
WHERE clause. Given the first SELECT's result of 0 for all rows, the second
SELECT should return no rows, and the third should return ids 1 through 8.

Additional observations:
The following EXPLAIN reports a zero-DATETIME literal in its filter:

    EXPLAIN FORMAT=JSON
    SELECT id FROM t1 WHERE DEFAULT(v)<dt ORDER BY id;

Observed filter:

    (TIMESTAMP'0000-00-00 00:00:00' < t1.dt)

This is an observed plan detail; the internal root cause has not been established.

As a control, run:

    SET SESSION sql_mode='STRICT_TRANS_TABLES,NO_ZERO_DATE,NO_ZERO_IN_DATE';
    SELECT id, (DEFAULT(v)<dt) AS p FROM t1 ORDER BY id;
    SELECT id FROM t1 WHERE DEFAULT(v)<dt ORDER BY id;
    SELECT id FROM t1 WHERE NOT(DEFAULT(v)<dt) ORDER BY id;

With this combination of modes, the results are consistent: p is 0 for every
row, the positive predicate selects no rows, and the negated predicate selects
all eight rows. The individual mode flags have not been isolated.

The empty-mode inconsistency was also reproduced in a fresh connection and
with repeated PREPARE/EXECUTE of the projection and WHERE queries.

Related report:
The submission system suggested bug #121327 as a possible related report. That report compares TIME with nonconstant strings. This reproducer instead compares DEFAULT(TIME) with a DATETIME column and demonstrates disagreement between SELECT-list evaluation and WHERE filtering. Whether the reports share an internal cause has not been established.

Suggested fix:
Preserve the comparison's temporal conversion semantics across projection,
predicate optimization, and execution. Add regression coverage for the
SELECT/WHERE/NOT WHERE consistency shown above.

Thank you for the bug report.
Verified as described.