¿Por qué incluyendo una zona horaria en una consulta MySQL DATETIME con miras hacer que los segundos fraccionarios no son equivalentes?

El engaño digital:

Tengo un 8 MySQL DB con un DATETIME(4)campo, y me he encontrado con un caso raro alrededor de equivalencia en una vista. He trabajado alrededor, pero no estoy seguro de por qué está sucediendo y me gustaría entender por qué.

---

Tengo una tabla con un campo: date_time DATETIME(4). Tengo una visión Donde a su vez esta de nuevo en una cadena utilizando ISO8601 DATE_FORMAT(date_time, '%Y-%m-%dT%T.%fZ') as date_time.

Si inserto una fila con una fecha como 2017-04-22T20:47:05.33523Z, a continuación, la siguiente consulta no encuentra la fila y no estoy seguro de por qué.

select * from EXAMPLE_VIEW where date_time >= '2017-04-22T20:47:05.335Z';

El siguiente trabajo de tareas:

select * from EXAMPLE where date_time >= '2017-04-22T20:47:05.335Z';
select * from EXAMPLE where date_time >= '2017-04-22T20:47:05.335';
select * from EXAMPLE where date_time >= '2017-04-22T20:47:05.3350Z';

select * from EXAMPLE_VIEW where date_time >= '2017-04-22T20:47:05.335';
select * from EXAMPLE_VIEW where date_time >= '2017-04-22T20:47:05.3350Z'

Mínimo ejemplo aquí: https://www.db-fiddle.com/f/ak7LTLzH7UJGgmPWS85dRE/1

Nick:

Su problema es que cuando se realiza la comparación en el VIEWque se comparan como cadenas , no fechas . Al dar formato a la fecha y hora de %fobtener 6 dígitos de microsegundos, es decir 2017-04-22T20:47:05.335200Z. Puesto que usted está comparando esto como una cadena, la >=comparación con '2017-04-22T20:47:05.335Z'falla porque 2es menos Z.

La razón de esta prueba funciona en la consulta 1 es que '2017-04-22T20:47:05.335Z'se convierte en una fecha (que resulta en 2017-04-22T20:47:05.335000Z) antes de la comparación, y que es menor que 2017-04-22T20:47:05.335200Z.