Repository navigation
Bind DateTime parameters as DATETIME so MariaDB keeps pre-1970 values - #252
Merged
Merged
Conversation
MariaDB stores NULL for a MYSQL_TYPE_TIMESTAMP parameter outside the TIMESTAMP range (before 1970 or after 2106), even in a DATETIME column, without a warning and in strict mode. DateTime parameters (and so MySQL.load of DateTime columns) silently lost every such value on MariaDB 11.4 and 11.8. Timestamp parameters already used MYSQL_TYPE_DATETIME; MySQL treats both types the same. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Merged
quinnj
referenced
this pull request
Oct 30, 2026
Co-authored-by: Jacob Quinn <quinn.jacobd@gmail.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
On MariaDB, a
DateTimeparameter before 1970 or after 2106 is stored as NULL. There is no warning, even in strict mode. This affects preparedexecute,execute(conn, sql, params),executemany, andMySQL.loadof aDateTimecolumn. MySQL is not affected.Cause:
DateTimeparameters were sent asMYSQL_TYPE_TIMESTAMP, which was the 1.x mapping. MariaDB applies the TIMESTAMP range to a TIMESTAMP-typed parameter and turns values outside it into NULL, even when the target column is DATETIME.Timestamp{P}parameters already usedMYSQL_TYPE_DATETIMEand were correct.Fix: bind
DateTimeasMYSQL_TYPE_DATETIME, the same asTimestamp.Before (MariaDB 11.4.13 and 11.8.9, column
DATETIME(3)):After: every value reads back unchanged on MariaDB 11.4.13, MariaDB 11.8.9, and MySQL 8.4.13.
Checks:
time_zone = '+05:30', usingUNIX_TIMESTAMPof the stored value.WHERE dt = ?with an out-of-rangeDateTimematched correctly before the fix, so only stored values were affected.test/user_workflow.jl, which runs on both live lanes. It inserts DateTime values from 1955, 1969, and 2200 withexecutemanyand withMySQL.load, then reads them back. Without the fix it fails 2 tests on MariaDB 11.4 and 11.8 (all three values read backmissing). With the fix it passes on all three servers. The serverless signature test now expectsMYSQL_TYPE_DATETIME.Pkg.test()locally on Julia 1.12.6, with Docker lanesmysql:8(8.4.13) andmariadb:11.4, the integration tests, and the--trim=safebuild: 2294/2294 passed.Found by a differential comparison of MySQL.jl against PyMySQL and an independent binary-protocol decoder, on MySQL 8.4 and MariaDB 11.8. Every type was checked through text and binary, buffered and streaming paths. This was the only value mismatch.
🤖 Generated with Claude Code