TIME format 00:00:00 return 102278627328:00:34

[Gabilabrebi]

When using TIME format and storing "00:00:00", the time retrieved when using SELECT is "102278627328:00:34"

For whatever reason, in a more complex query like the one bellow, it even crashes node.

SELECT
    boxes.id,
    boxes.title,
    boxes.active,
    boxes.startDate,
    boxes.endDate,
    boxes.monday,
    boxes.tuesday,
    boxes.wednesday,
    boxes.thursday,
    boxes.friday,
    boxes.saturday,
    boxes.sunday,
    boxes.startHour,
    boxes.endHour,
    IF(COUNT(boxes_contents.id) = 0, JSON_ARRAY(), JSON_ARRAYAGG(JSON_OBJECT("type", boxes_contents.type, "id", boxes_contents.refId, "level",boxes_contents.level) ORDER BY sort)) AS content
FROM boxes
LEFT JOIN boxes_contents ON boxes_contents.boxe = boxes.id
WHERE boxes.userId = ?
GROUP BY boxes.id

undefined:1
e": "category", "id": 1, "level": 1},{"type": "item", "id": 1, "level": null},{"type": "item", "id": 2, "level":
^

SyntaxError: Unexpected token 'e', "e": "categ"... is not valid JSON
    at JSON.parse (<anonymous>)
    at Array.readJsonBinary (C:\Users\Gabi\Documents\Web\menu\node_modules\mariadb\lib\cmd\decoder\binary-decoder.js:268:49)
    at Execute.parseRowStdBinary (C:\Users\Gabi\Documents\Web\menu\node_modules\mariadb\lib\cmd\parser.js:530:56)
    at Execute.readResultSetRow (C:\Users\Gabi\Documents\Web\menu\node_modules\mariadb\lib\cmd\parser.js:428:29)
    at PacketInputStream.receivePacketBasic (C:\Users\Gabi\Documents\Web\menu\node_modules\mariadb\lib\io\packet-input-stream.js:85:9)
    at PacketInputStream.onData (C:\Users\Gabi\Documents\Web\menu\node_modules\mariadb\lib\io\packet-input-stream.js:145:26)
    at Socket.emit (node:events:515:28)
    at addChunk (node:internal/streams/readable:545:12)
    at readableAddChunkPushByteMode (node:internal/streams/readable:495:3)
    at Readable.push (node:internal/streams/readable:375:5)

Node.js v21.1.0
[nodemon] app crashed - waiting for file changes before starting...

Obviously the same SELECT works fine with every other TIME than 00:00:00

[rusher]

Thanks for reporting it.
Problem reside in binary encoded of TIME with exact value of '00:00:00' as indicated.
This will be corrected in 3.2.3