gitbutlerapp/gitbutler · error

fetch timestamp does not fit in the database: {err}

Error message

fetch timestamp does not fit in the database: {err}

What it means

The fetch timestamp is computed as u128 milliseconds and then narrowed into the i64 stored in the database; a clock beyond roughly year 292 million overflows the narrowing and this guard fires. In practice only a badly corrupted or manipulated clock can trigger it. The check exists so an absurd timestamp fails loudly instead of silently corrupting fetch_status records.

Source

Thrown at crates/but-api/src/workspace.rs:130

                    .iter()
                    .map(|(remote, err)| format!("{remote}: {err}"))
                    .collect::<Vec<_>>()
                    .join("\n");
                let err = anyhow::anyhow!(joined);
                Err(match code {
                    Some(code) => err.context(code),
                    None => err,
                })
            }
        }
    })();

    let attempted_ms = SystemTime::now()
        .duration_since(UNIX_EPOCH)
        .map_err(|err| anyhow::anyhow!("system clock is before the Unix epoch: {err}"))?
        .as_millis()
        .try_into()
        .map_err(|err| anyhow::anyhow!("fetch timestamp does not fit in the database: {err}"))?;
    let _guard = ctx.exclusive_worktree_access();
    match &fetch_result {
        Ok(()) => ctx
            .db
            .get_cache_mut()?
            .fetch_status_mut()
            .record_success(attempted_ms)?,
        Err(err) => ctx
            .db
            .get_cache_mut()?
            .fetch_status_mut()
            .record_failure(attempted_ms, &format!("{err:#}"))?,
    }

    // A partial failure may still have updated some remote refs.
    ctx.invalidate_workspace_cache()?;
    prune_missing_branch_stack_order(ctx)?;
    fetch_result

View on GitHub (pinned to 2497b8007a)

Solutions

1. Correct the system date and verify with `date -u`.
2. If it reproduces on one host only, treat it as hardware/hypervisor clock failure rather than a software bug.

const ms = Date.now();
if (!Number.isSafeInteger(ms) || ms < 0) {
  throw new Error('system clock reports an implausible time');
}

catch (e) {
  if (String(e.message).includes('fetch timestamp does not fit in the database')) {
    showFatalError('Host clock invalid', 'The system date is set far in the future; correct it and retry.');
  }
}

When it happens

Trigger: A workspace fetch on a host whose clock is set astronomically far into the future — corrupted RTC, hypervisor clock bug, or clock mocking past i64::MAX milliseconds — so u128 millis no longer fits i64.

Common situations: Essentially never in normal use; occasionally seen on flaky embedded boards, after CMOS corruption, or in test rigs that monkeypatch the clock far out of range.

Related errors

• system clock is before the Unix epoch: {err}
• Failed to persist action: {e}
• Failed to list actions: {e}
• Failed to execute command {cmd:?}

AI-assisted analysis of gitbutlerapp/gitbutler@2497b8007a (2026-08-17). Data as JSON: /api/errors/0455c50f55a97115. Report an issue: GitHub.