SQLGetData/SQLFetch of an out-of-range time silently truncates the hour and returns SQL_SUCCESS

Start in mssql-odbc/src/conversion/datetime.rs at hms_from_ticks_100ns, then inspect time_parts and datetime2_parts in mssql-odbc/src/conversion/fetch_convert.rs. Reproduce the DateTime2 example from the issue and add coverage for an out-of-range tick field. Done means SQLGetData and block fetch return a normal conversion error rather than SQL_SUCCESS with an invalid hour.

Describe the bug

hms_from_ticks_100ns (mssql-odbc/src/conversion/datetime.rs:161) computes the clock fields from a 100 ns tick count with no range check:

TimeOfDay {
    hour: (secs / 3600) as u16,
    minute: ((secs % 3600) / 60) as u16,
    second: (secs % 60) as u16,
    fraction_ns,
}

secs / 3600 is truncated with as u16 instead of validated. A valid time-of-day is < 24 * 3600 * 10_000_000 ticks; any larger time_nanoseconds (the decoder's name for the 100 ns tick field) produces an hour outside 0..=23, silently wrapped into 0..=65535, and the conversion still reports Ok(ConvOk::Exact) → SQL_SUCCESS.

The callers time_parts and datetime2_parts (mssql-odbc/src/conversion/fetch_convert.rs) don't range-check the ticks either, so a corrupt or hostile server row that decodes to an out-of-range time is handed back through SQLGetData / block fetch as a successful conversion with a wrong value. This is the value-correctness sibling of the datetimeoffset overflow fixed in #511 — that path had an i64 add that panicked; these paths have no add, so they truncate instead of panicking, which is why a fuzzer that only watches for panics can't surface it.

Steps to reproduce

Convert a DateTime2 (or Time) column whose tick field is outside a single day into SQL_C_TYPE_TIMESTAMP (or SQL_C_TYPE_TIME). Throwaway unit test that demonstrates it:

let dt2 = ColumnValues::DateTime2(SqlDateTime2 {
    days: 0,
    time: SqlTime { time_nanoseconds: i64::MAX as u64, scale: 7 },
});
// convert dt2 to SQL_C_TYPE_TIMESTAMP

Expected behavior

An out-of-range tick count is rejected as a conversion error (e.g. ODBC 22007 / a None → normal ODBC conversion error), the same way datetimeoffset_parts now rejects out-of-range days via the 0..=MAX_DAYS_SINCE_0001 check — never a wrong value under SQL_SUCCESS.

Actual behavior

Returns Ok(ConvOk::Exact) / SQL_SUCCESS with a truncated, out-of-range field, e.g.:

SqlTimestampStruct { year: 1, month: 1, day: 1, hour: 24554, minute: 48, second: 5, fraction: 477580700 }

hour: 24554 is handed back in a SQLUSMALLINT under a success return.

Version

commit 4ca532ae (branch dev/saurabh/odbc-fuzz-testing)

Affected crate

mssql-odbc

Environment

• OS: Ubuntu 22.04 (also platform-independent)
• Not tied to a specific SQL Server version — reproducible from any row that decodes to an out-of-range time tick count.

Additional context

Surfaced while reviewing the ODBC fuzz PR #511. It is pre-existing (not introduced by that PR) and out of scope for it, so it is filed separately. A range check belongs in hms_from_ticks_100ns or in each caller (time_parts, datetime2_parts) before the fields are trusted.