{"record":{"id":"1be4717fd5be21e9","repo":"napi-rs/napi-rs","slug":"found-invalid-date","errorCode":null,"errorMessage":"Found invalid date","messagePattern":"Found invalid date","errorType":"validation","errorClass":"DateExpected","httpStatus":null,"severity":"error","filePath":"crates/napi/src/bindgen_runtime/js_values/date.rs","lineNumber":148,"sourceCode":"    Ok(ptr)\n  }\n}\n\nimpl<Tz: TimeZone> FromNapiValue for DateTime<Tz>\nwhere\n  DateTime<Tz>: From<DateTime<Local>>,\n{\n  unsafe fn from_napi_value(env: sys::napi_env, napi_val: sys::napi_value) -> Result<Self> {\n    let mut milliseconds_since_epoch_utc = 0.0;\n\n    check_status!(\n      unsafe { sys::napi_get_date_value(env, napi_val, &mut milliseconds_since_epoch_utc) },\n      \"Failed to convert napi value into rust type `DateTime`\",\n    )?;\n\n    match Local.timestamp_millis_opt(milliseconds_since_epoch_utc as i64) {\n      LocalResult::Single(dt) => Ok(dt.into()),\n      _ => Err(Error::new(\n        Status::DateExpected,\n        \"Found invalid date\".to_owned(),\n      )),\n    }\n  }\n}\n","sourceCodeStart":130,"sourceCodeEnd":155,"githubUrl":"https://github.com/napi-rs/napi-rs/blob/39bd1205e480a453a2da2601a760bde5a71ed016/crates/napi/src/bindgen_runtime/js_values/date.rs#L130-L155","documentation":"Thrown when converting a JS Date to `DateTime<Local>`: `napi_get_date_value` returns milliseconds since epoch, and `Local.timestamp_millis_opt` fails to produce a unique/valid local datetime (LocalResult::None or Ambiguous). The library raises Status::DateExpected with this message instead of returning a DateTime.","triggerScenarios":"Calling a #[napi] function with a `DateTime<Local>` (or `DateTime<Utc>` mapped through this impl) parameter when the epoch milliseconds map to a nonexistent or ambiguous local time, or the JS value is an invalid Date (NaN time, e.g. `new Date(NaN)`).","commonSituations":"DST transitions where `new Date(...)` epoch value maps into a skipped/ambiguous local hour in the user's timezone; passing `new Date(undefined)` or `Invalid Date` from JS.","solutions":["Validate the Date on the JS side before calling: check `!Number.isNaN(date.getTime())`.","Verify the epoch milliseconds do not fall into a DST gap for the machine's local timezone, or use a UTC-based type (`DateTime<Utc>` vs `NaiveDateTime`) on the Rust side.","Set the process/container TZ to a known zone (e.g. TZ=UTC) if DST ambiguity is the cause.","Inspect the incoming Date with `date.toISOString()` in JS to confirm it represents a real instant."],"exampleFix":"// before\nfn schedule(dt: DateTime<Local>) { ... }\nschedule(new Date(undefined));\n// after (JS side guard)\nconst d = new Date(input);\nif (Number.isNaN(d.getTime())) throw new Error('invalid date');\nschedule(d);","handlingStrategy":"validation","validationCode":"function assertValidDate(d) {\n  if (!(d instanceof Date) || Number.isNaN(d.getTime())) {\n    throw new TypeError('Expected a valid Date, got: ' + String(d));\n  }\n}","typeGuard":"function isValidDate(v) { return v instanceof Date && !Number.isNaN(v.getTime()); }","tryCatchPattern":"try { mod.schedule(d); } catch (e) { if (String(e.message).includes('Found invalid date')) { console.error('Date invalid or falls in DST gap'); } else throw e; }","preventionTips":["Always validate Date values with Number.isNaN(d.getTime()) before native calls.","Avoid constructing dates inside DST gap hours from local components (new Date(2024,2,10,2,30) in affected zones).","Prefer UTC-based timestamps (epoch millis) when crossing timezone boundaries.","Pin TZ (e.g. TZ=UTC) in CI and containers for deterministic behavior."],"tags":["date","timezone","dst","chrono"],"backgroundTag":"invalid-date-format","analyzedSha":"39bd1205e480a453a2da2601a760bde5a71ed016","analyzedAt":"2026-09-13T20:31:47.814Z","contentChangedAt":"2026-09-13T20:31:47.814Z","schemaVersion":2},"datasetVersion":"2026-09-16T09:17:16.951Z"}