SeaQL/sea-orm · error

Failed to get date

Error message

Failed to get date

What it means

This panic comes from the `with-chrono` DATE branch of `ProxyRow` in the MySQL driver: `sqlx::Row::try_get::<Option<chrono::NaiveDate>, _>` failed for a "DATE" column at `c.ordinal()`. The `expect` turns the sqlx decode failure into a panic with "Failed to get date". It means the value cannot be decoded as a `chrono::NaiveDate`, typically because the column no longer holds DATE data or contains out-of-range/zero dates.

Source

Thrown at sea-orm-sync/src/driver/sqlx_mysql.rs:459

                        }

                        #[cfg(feature = "with-chrono")]
                        "TIMESTAMP" => Value::ChronoDateTimeUtc(
                            row.try_get::<Option<chrono::DateTime<chrono::Utc>>, _>(c.ordinal())
                                .expect("Failed to get timestamp")
                                .map(Box::new),
                        ),
                        #[cfg(all(feature = "with-time", not(feature = "with-chrono")))]
                        "TIMESTAMP" => Value::TimeDateTime(
                            row.try_get::<Option<time::PrimitiveDateTime>, _>(c.ordinal())
                                .expect("Failed to get timestamp")
                                .map(Box::new),
                        ),

                        #[cfg(feature = "with-chrono")]
                        "DATE" => Value::ChronoDate(
                            row.try_get::<Option<chrono::NaiveDate>, _>(c.ordinal())
                                .expect("Failed to get date")
                                .map(Box::new),
                        ),
                        #[cfg(all(feature = "with-time", not(feature = "with-chrono")))]
                        "DATE" => Value::TimeDate(
                            row.try_get::<Option<time::Date>, _>(c.ordinal())
                                .expect("Failed to get date")
                                .map(Box::new),
                        ),

                        #[cfg(feature = "with-chrono")]
                        "TIME" => Value::ChronoTime(
                            row.try_get::<Option<chrono::NaiveTime>, _>(c.ordinal())
                                .expect("Failed to get time")
                                .map(Box::new),
                        ),
                        #[cfg(all(feature = "with-time", not(feature = "with-chrono")))]
                        "TIME" => Value::TimeTime(
                            row.try_get::<Option<time::Time>, _>(c.ordinal())

View on GitHub (pinned to e29bcd1b41)

Solutions

  1. Refresh the table metadata so DATE mapping matches the live schema (`SHOW CREATE TABLE`).
  2. Find and fix zero-dates ('0000-00-00') or out-of-range dates in the table; set sql_mode to reject them going forward.
  3. Verify the column is genuinely DATE and not DATETIME/VARCHAR; adjust schema or query.
  4. Patch the driver to return DbErr instead of `expect` so the real decode error is reported.

Example fix

// before
"DATE" => Value::ChronoDate(
    row.try_get::<Option<chrono::NaiveDate>, _>(c.ordinal())
        .expect("Failed to get date")
        .map(Box::new),
)
// after
"DATE" => Value::ChronoDate(
    row.try_get::<Option<chrono::NaiveDate>, _>(c.ordinal())
        .map_err(|e| DbErr::TryGetErr(...))? // propagate instead of panicking
        .map(Box::new),
)
Defensive patterns

Strategy: validation

Validate before calling

// Ensure DATE columns hold valid dates before querying
// SELECT COUNT(*) FROM t WHERE d = '0000-00-00'; must be 0
assert_eq!(col.type_name, "DATE");

Try / catch

// The panic is raised by .expect in the driver; guard the call site:
std::panic::catch_unwind(|| proxy_row_from(&row, &columns))
    .map_err(|_| DbErr::Custom("DATE column decode failed".into()))?

Prevention

When it happens

Trigger: Reading a MySQL DATE column while compiled with `with-chrono`, when the raw value is not decodable as `chrono::NaiveDate` — e.g. metadata says DATE but the column is now VARCHAR/DATETIME, or MySQL zero-date '0000-00-00' is present.

Common situations: Legacy MySQL data with zero-dates; schema drift after ALTER TABLE; using stale table metadata captured before a column type change.

Understand the failure class

Background: Type mismatch errors: IllegalArgumentException, TypeError and type guards across 150 open-source libraries — this error's family across 150 libraries.

Related errors


AI-assisted analysis of SeaQL/sea-orm@e29bcd1b41 (2026-09-10). Data as JSON: /api/errors/dd13a6feeb9892ff. Report an issue: GitHub.