What causes "failed to parse the since time: %w" in cilium/cilium?

Use a valid relative duration like --since 5m, 1h, or 24h

failed to parse the since time: %w

Error message

failed to parse the since time: %w

What it means

The --since flag value is parsed with hubtime.FromString, which accepts relative durations (e.g. 5m) and absolute timestamps. If parsing fails, getFlowsRequest wraps the underlying error with this message, aborting request construction.

Source

Thrown at hubble/cmd/observe/flows.go:784

	if first && last {
		return nil, fmt.Errorf("cannot set both --first and --last")
	}
	if first && selectorOpts.all {
		return nil, fmt.Errorf("cannot set both --first and --all")
	}
	if first && selectorOpts.follow {
		return nil, fmt.Errorf("cannot set both --first and --follow")
	}
	if last && selectorOpts.all {
		return nil, fmt.Errorf("cannot set both --last and --all")
	}

	// convert selectorOpts.since into a param for GetFlows
	var since, until *timestamppb.Timestamp
	if selectorOpts.since != "" {
		st, err := hubtime.FromString(selectorOpts.since)
		if err != nil {
			return nil, fmt.Errorf("failed to parse the since time: %w", err)
		}

		since = timestamppb.New(st)
		if err := since.CheckValid(); err != nil {
			return nil, fmt.Errorf("failed to convert `since` timestamp to proto: %w", err)
		}
	}
	// Set the until field if --until option is specified and --follow
	// is not specified. If --since is specified but --until is not, the server sets the
	// --until option to the current timestamp.
	if selectorOpts.until != "" && !selectorOpts.follow {
		ut, err := hubtime.FromString(selectorOpts.until)
		if err != nil {
			return nil, fmt.Errorf("failed to parse the until time: %w", err)
		}
		until = timestamppb.New(ut)
		if err := until.CheckValid(); err != nil {
			return nil, fmt.Errorf("failed to convert `until` timestamp to proto: %w", err)

View on GitHub (pinned to ac7b90affa)

Solutions

Use a valid relative duration like --since 5m, 1h, or 24h
Use an RFC3339 absolute timestamp, e.g. --since 2024-01-01T00:00:00Z
Run `hubble observe --help` / check hubtime.FromString docs for accepted formats
Quote the value in shell to avoid mangling (e.g. --since '5m')

Example fix

// before
hubble observe --since 5 mins ago
// after
hubble observe --since 5m

Defensive patterns

Strategy: validation

Validate before calling

func validSince(s string) error {
    if s == "" { return nil }
    if _, err := hubtime.FromString(s); err != nil {
        return fmt.Errorf("--since %q unparseable: %w", s, err)
    }
    return nil
}

Try / catch

req, err := getFlowsRequest(ofilter, allow, deny)
if err != nil && strings.HasPrefix(err.Error(), "failed to parse the since") {
    return fmt.Errorf("check --since format (e.g. 5m or RFC3339): %w", err)
}

Prevention

Prefer simple relative durations (5m, 1h, 24h) in scripts
Always quote time flags in shell
Add pre-flight validation of --since/--until values in wrappers
Test scripts with the exact timestamp formats they emit

When it happens

Trigger: Running `hubble observe --since blah`, `--since 2024-13-01` (invalid date), or an unparseable relative duration like `--since 5mins`.

Common situations: Shell quoting stripping units or adding stray characters; assuming arbitrary date formats are accepted (e.g. US-format MM/DD/YYYY); timezone-suffixed strings not supported by the parser.

Understand the failure class

Parsing and encoding errors: unexpected token, malformed input — why parsers reject input and how to find the real culprit.

Related errors

AI-assisted analysis of cilium/cilium@ac7b90affa (2026-08-31). Data as JSON: /api/errors/0d906bbe19d94519. Report an issue: GitHub.