What causes "invalid timestamp %q: %w" in larksuite/cli?

Use a standard, unambiguous time format (RFC3339 like '2026-09-04T10:00:00+08:00' or 'YYYY-MM-DD HH:MM').

invalid timestamp %q: %w

Error message

invalid timestamp %q: %w

What it means

toUnixSeconds first converts user time input via common.ParseTime, then validates the result is a parseable 64-bit integer Unix timestamp. If ParseInt fails, it wraps the cause as 'invalid timestamp %q: %w'. This is an intermediate parse error; callers (parseMeetingEventsTimeRange) wrap it into a typed ValidationError.

Source

Thrown at shortcuts/vc/vc_meeting_events.go:44

	defaultVCMeetingEventsSize = 20
	minVCMeetingEventsPageSize = 20
	maxVCMeetingEventsPageSize = 100
	maxVCMeetingEventsPages    = 200
	leaveReasonUserLeft        = 1
	leaveReasonMeetingEnded    = 2
	leaveReasonKicked          = 3
)

var meetingDisplayLocation = time.FixedZone("UTC+8", 8*60*60)

// toUnixSeconds converts a supported CLI time input into a Unix seconds string.
func toUnixSeconds(input string, hint ...string) (string, error) {
	ts, err := common.ParseTime(input, hint...)
	if err != nil {
		return "", err
	}
	if _, err := strconv.ParseInt(ts, 10, 64); err != nil {
		return "", fmt.Errorf("invalid timestamp %q: %w", ts, err) //nolint:forbidigo // intermediate parse error; callers wrap it into a typed ValidationError
	}
	return ts, nil
}

// VCMeetingEvents lists meeting events for a meeting.
var VCMeetingEvents = common.Shortcut{
	Service:     "vc",
	Command:     "+meeting-events",
	Description: "List meeting events by meeting ID",
	Risk:        "read",
	// UAT exposes user-granted scopes, so the framework can preflight the user
	// recommendation. TAT has no scope metadata; keep the bot recommendation
	// conditional so it is available to diagnostics without a local preflight.
	UserScopes:           []string{meetingQueryUserScope},
	ConditionalBotScopes: []string{meetingQueryBotScope},
	AuthTypes:            []string{"user", "bot"},
	HasFormat:            true,
	Flags: []common.Flag{

View on GitHub (pinned to 7fd6ef3c07)

Solutions

Use a standard, unambiguous time format (RFC3339 like '2026-09-04T10:00:00+08:00' or 'YYYY-MM-DD HH:MM').
Check the wrapped cause after 'invalid timestamp' to see why the integer conversion failed.
If providing raw Unix seconds, supply a plain integer like '1780000000'.
Check --help/schema for accepted --start/--end formats for the meeting events command.

Example fix

// before
--start "04/09/2026 10am"
// after
--start "2026-09-04T10:00:00+08:00"

Defensive patterns

Strategy: validation

Validate before calling

ts, err := common.ParseTime(input)
if err != nil { return err }
if _, err := strconv.ParseInt(ts, 10, 64); err != nil {
	return fmt.Errorf("--start/--end must resolve to Unix seconds, got %q", ts)
}

Type guard

func isUnixSecondsString(s string) bool {
	_, err := strconv.ParseInt(strings.TrimSpace(s), 10, 64)
	return err == nil
}

Try / catch

if err != nil {
	var ve *errs.ValidationError
	if errors.As(err, &ve) { return hintUsage(ve, "use RFC3339 or Unix seconds for --start/--end") }
	return err
}

Prevention

Pass RFC3339 or plain Unix-seconds strings to --start/--end.
Avoid locale-specific date formats in scripts.

When it happens

Trigger: Calling VC meeting events with --start/--end values that ParseTime accepts but that do not yield an integer string — practically, when ParseTime is configured/extended to return non-numeric output or the input bypasses normal parsing, since ParseTime's own failure is returned unwrapped first.

Common situations: Passing exotic date formats that a customized parser produced non-numeric output for, or feeding a pre-formatted value through a path where ParseTime passes it through unvalidated.

Related errors

AI-assisted analysis of larksuite/cli@7fd6ef3c07 (2026-09-04). Data as JSON: /api/errors/0ede3968fcd3030f. Report an issue: GitHub.