risingwavelabs/risingwave · error · InvalidParamsError
Invalid time: secs: {secs}, nanoseconds: {nsecs}
Error message
Invalid time: secs: {secs}, nanoseconds: {nsecs} What it means
ErrorKind::Time is an internal error kind in RisingWave's datetime type conversion (src/common/src/types/datetime.rs) indicating a time-of-day value with seconds/nanoseconds that cannot form a valid NaiveTime. The conversion via Time::from_num_seconds_from_midnight requires secs < 86400 and nsecs < 1_000_000_000; violating either produces 'Invalid time: secs: <u32>, nanoseconds: <u32>'.
Source
Thrown at src/common/src/types/datetime.rs:251
///
/// let interval = Interval::from_month_day_usec(0, 0, -61000003);
/// let time = Time::from(interval);
/// assert_eq!(time, Time::from_str("23:58:58.999997").unwrap());
/// ```
impl From<Interval> for Time {
fn from(interval: Interval) -> Self {
let usecs = interval.usecs_of_day();
let secs = (usecs / 1_000_000) as u32;
let nano = (usecs % 1_000_000 * 1000) as u32;
Time::from_num_seconds_from_midnight_uncheck(secs, nano)
}
}
#[derive(Copy, Clone, Debug, Error)]
enum ErrorKind {
#[error("Invalid date: days: {days}")]
Date { days: i32 },
#[error("Invalid time: secs: {secs}, nanoseconds: {nsecs}")]
Time { secs: u32, nsecs: u32 },
#[error("Invalid time: {value} {unit} is out of range for a time of day")]
TimeOfDay { value: u64, unit: &'static str },
#[error("Invalid datetime: seconds: {secs}, nanoseconds: {nsecs}")]
DateTime { secs: i64, nsecs: u32 },
#[error("Invalid datetime: {value} {unit} is out of range")]
Timestamp { value: i64, unit: &'static str },
#[error("Can't cast string to date (expected format is YYYY-MM-DD)")]
ParseDate,
#[error(
"Can't cast string to time (expected format is HH:MM:SS[.D+{{up to 6 digits}}][Z] or HH:MM)"
)]
ParseTime,
#[error(
"Can't cast string to timestamp (expected format is YYYY-MM-DD HH:MM:SS[.D+{{up to 9 digits}}] or YYYY-MM-DD HH:MM or YYYY-MM-DD or ISO 8601 format)"
)]
ParseTimestamp,
}View on GitHub (pinned to 6469eb736d)
Solutions
- Ensure secs < 86400 and nsecs < 1_000_000_000 before conversion (normalize with modulo/reminding).
- Convert seconds-of-day values via date-aware timestamp functions instead of direct TIME casting.
- Sanitize numeric input data before casting to TIME.
Example fix
// before let time = Time::with_secs_nanos(90000, 0)?; // after let time = Time::with_secs_nanos(secs % 86400, 0)?;
Defensive patterns
Strategy: validation
Validate before calling
// Pre-check time components before conversion
fn valid_time(secs: u32, nsecs: u32) -> bool {
secs < 86_400 && nsecs < 1_000_000_000
} Try / catch
match Time::from_num_seconds_from_midnight(secs, nano) {
Ok(t) => t,
Err(e) if e.to_string().starts_with("Invalid time: secs") => {
log::warn!("invalid time secs={secs} nsecs={nsecs}, normalizing");
Time::from_num_seconds_from_midnight(secs % 86_400, nsecs % 1_000_000_000)?
}
Err(e) => return Err(e.into()),
} Prevention
- Normalize seconds-of-day with modulo 86400 before TIME conversion.
- Never feed epoch timestamps directly into TIME casts; use timestamp functions.
- Validate nanosecond fields are < 1e9 when accepting external precision data.
When it happens
Trigger: Calling Time conversion helpers (e.g. Time::from_num_seconds_from_midnight or from-unchecked counterparts guarded by validation in src/common/src/types/datetime.rs) with secs >= 86400 or nsecs >= 1_000_000_000, typically from numeric casts of user data.
Common situations: Casting raw epoch-second values to TIME; passing nanosecond-precision values into a microsecond field; computed time arithmetic that exceeds one day without normalization.
Understand the failure class
Background: "value must be between 0 and 1" / "out of range" / "must not be negative" errors: fixing range-validation failures across open-source libraries — this error's family across 42 libraries.
Related errors
- Invalid date: days: {days}
- Invalid time: {value} {unit} is out of range for a time of d
- invalid Time value encoding: secs: {0} nano: {1}
- unrecognized configs: {:?}
- Unsupported parallelism: {0}
AI-assisted analysis of risingwavelabs/risingwave@6469eb736d (2026-09-11).
Data as JSON: /api/errors/b0127f18b0c42d76.
Report an issue: GitHub.