nautechsystems/nautilus_trader · error

system clock overflowed when converting to i64

Error message

system clock overflowed when converting to i64

What it means

build_auth_token_for converts the seconds-since-epoch value to i64 before computing the token deadline. If the seconds count exceeds i64::MAX (far beyond year 2262), i64::try_from fails and this error is raised. This guards deadline arithmetic from silent overflow; in practice it indicates an absurd system clock rather than a normal condition.

Source

Thrown at crates/adapters/lighter/src/signing/auth_token.rs:124

/// The token format matches the Go reference's `ConstructAuthToken`. The
/// returned string is the value the WebSocket subscribe handshake sends in
/// the `auth` field of an `account_*` channel subscription.
///
/// # Errors
///
/// Returns the underlying [`crate::common::credential::Credential::private_key`]
/// failure if the secret cannot be decoded, or any [`build_auth_token`]
/// failure (clock-before-epoch or, hypothetically, a breach caused by its own
/// deadline validation).
pub fn build_auth_token_for(
    credential: &crate::common::credential::Credential,
) -> anyhow::Result<SecretString> {
    let now = SystemTime::now()
        .duration_since(UNIX_EPOCH)
        .map_err(|_| anyhow::anyhow!("system clock is before UNIX epoch"))?
        .as_secs();
    let now_i64 = i64::try_from(now)
        .map_err(|_| anyhow::anyhow!("system clock overflowed when converting to i64"))?;
    let deadline = now_i64
        .checked_add(DEFAULT_AUTH_TOKEN_TTL_SECS)
        .ok_or_else(|| anyhow::anyhow!("deadline computation overflowed"))?;
    let sk = credential.private_key()?;
    build_auth_token(
        deadline,
        credential.account_index(),
        credential.api_key_index(),
        &sk,
        fresh_k(),
    )
    .map_err(|e| anyhow::anyhow!("failed to mint Lighter auth token: {e}"))
}

/// Draws a fresh canonical [`Scalar`] from the thread-local CSPRNG suitable
/// for the per-signature `k` nonce.
///
/// The Schnorr binding requires `k` to be drawn from a cryptographic RNG and

View on GitHub (pinned to 18893faf8b)

Solutions

  1. Inspect the system clock (`date -u +%s`) — a value near 9e18 indicates an OS/hypervisor time bug.
  2. Fix the time source (NTP resync, VM tools, host clock) and retry.
  3. If this occurs in tests, ensure any time mocking returns realistic epoch values.
  4. Report the runtime/environment bug if the OS consistently reports impossible times.

Example fix

// before (mocked time in a test harness)
SystemTime::now = () => SystemTime::UNIX_EPOCH + Duration::from_secs(i64::MAX as u64)
// after
SystemTime::now = () => SystemTime::UNIX_EPOCH + Duration::from_secs(1_700_000_000)
Defensive patterns

Strategy: try-catch

Validate before calling

// Sanity-check the clock before authenticating
let secs = std::time::SystemTime::now().duration_since(std::time::UNIX_EPOCH)?.as_secs();
anyhow::ensure!(secs < i64::MAX as u64 / 2, "implausible system time {secs}");

Try / catch

match build_auth_token_for(&credential) {
    Ok(t) => t,
    Err(e) if e.to_string().contains("overflowed when converting") => {
        eprintln!("system time is absurd; fix OS/hypervisor clock");
        Err(e)
    }
    Err(e) => Err(e),
}

Prevention

When it happens

Trigger: Any authenticated call (auth token builders listed in callers) running on a system whose UNIX seconds since epoch exceed i64::MAX — e.g. corrupted clock libraries or mocked/faulty SystemTime sources returning huge values.

Common situations: Faulty or mocked time sources in exotic runtimes; integer-corrupted environment; practically never on a healthy host since real epoch seconds (~1.7e9) fit easily in i64.

Related errors


AI-assisted analysis of nautechsystems/nautilus_trader@18893faf8b (2026-09-08). Data as JSON: /api/errors/83bbb81bf4dd8a50. Report an issue: GitHub.