risingwavelabs/risingwave · error
anyhow!(e)
Error message
anyhow!(e)
What it means
In to_batch_query_epoch, when the AS OF timestamp string has no timezone offset, RisingWave resolves the session time zone via TIME_ZONE::try_with and Timestamptz::lookup_time_zone; if the session time zone name is unknown/invalid, the lookup error is wrapped with anyhow! and propagated.
Solutions
- Run `SET TIME ZONE` with a valid IANA time zone name (e.g. 'America/New_York') before the time travel query.
- Include an explicit offset in the AS OF timestamp (e.g. '...T10:00:00+08:00') so the session time zone is not consulted.
- Reset the session time zone to default (`SET TIME ZONE 'UTC'`).
Example fix
// before SET TIME ZONE 'PST'; -- invalid/unknown SELECT * FROM t AS OF TIMESTAMP '2024-01-01T10:00:00'; // after SET TIME ZONE 'America/Los_Angeles'; SELECT * FROM t AS OF TIMESTAMP '2024-01-01T10:00:00';
Defensive patterns
Strategy: validation
Validate before calling
// verify session tz before timezone-less time travel queries
let tz = "America/Los_Angeles";
assert!(tz.parse::<chrono_tz::Tz>().is_ok(), "unknown time zone: {}", tz); Type guard
fn is_known_tz(name: &str) -> bool { name.parse::<chrono_tz::Tz>().is_ok() } Try / catch
match res {
Err(e) if /* tz lookup failure */ e.to_string().to_lowercase().contains("time zone") || e.to_string().contains("failed to parse the timestamp") => eprintln!("SET TIME ZONE to a valid IANA zone or add an offset to the timestamp"),
other => other?,
} Prevention
- Use only IANA time zone names in SET TIME ZONE.
- Always include an explicit offset in AS OF timestamps.
- Avoid letting connection pools carry stale/invalid TimeZone settings.
When it happens
Trigger: Running `SET TIME ZONE '<bad name>'` (or a session with an invalid TimeZone setting) and then a time travel query with a timezone-less AS OF timestamp string, e.g. AS OF TIMESTAMP '2024-01-01T10:00:00'.
Common situations: Session configured with a wrong or unsupported time zone identifier (misspelled IANA zone, fixed offset string the parser rejects); connection pools carrying a stale SET TIME ZONE.
Understand the failure class
Background: "Must be a positive integer", "Invalid value", "Unsupported": the invalid-argument-value error family, when a library rejects the value you pass — this error's family across 35 libraries.
Related errors
- failed to parse the timestamp
- failed to parse the interval
- failed to parse the timestamp
- invalid timestamp
- number or string
AI-assisted analysis of risingwavelabs/risingwave@6469eb736d (2026-09-11).
Data as JSON: /api/errors/ec76b27f2fcc8ae2.
Report an issue: GitHub.
Appendix: source
Thrown at src/frontend/src/optimizer/plan_node/utils.rs:529
};
Feature::TimeTravel.check_available()?;
let timestamp = match a {
AsOf::ProcessTime | AsOf::ProcessTimeBroadcast => {
return Err(ErrorCode::NotSupported(
"AS OF PROCTIME is not supported".to_owned(),
"please use AS OF TIMESTAMP".to_owned(),
)
.into());
}
AsOf::TimestampNum(ts) => *ts,
AsOf::TimestampString(ts) => {
let date_time = speedate::DateTime::parse_str_rfc3339(ts)
.map_err(|_e| anyhow!("failed to parse the timestamp"))?;
if date_time.time.tz_offset.is_none() {
// If the input does not specify a time zone, use the time zone set by the "SET TIME ZONE" command.
risingwave_expr::expr_context::TIME_ZONE::try_with(|set_time_zone| {
let tz =
Timestamptz::lookup_time_zone(set_time_zone).map_err(|e| anyhow!(e))?;
match tz.with_ymd_and_hms(
date_time.date.year.into(),
date_time.date.month.into(),
date_time.date.day.into(),
date_time.time.hour.into(),
date_time.time.minute.into(),
date_time.time.second.into(),
) {
MappedLocalTime::Single(d) => Ok(d.timestamp()),
MappedLocalTime::Ambiguous(_, _) | MappedLocalTime::None => {
Err(anyhow!(format!(
"failed to parse the timestamp {ts} with the specified time zone {tz}"
)))
}
}
})??
} else {
date_time.timestamp_tz()View on GitHub (pinned to 6469eb736d)