lima-vm/lima · error

invalid date value: %w

Error message

invalid date value: %w

What it means

The plist parser decodes <date> elements with Go's time.Parse(time.RFC3339, ...). If the element's text content is not a valid RFC3339 timestamp, UnmarshalXML (pkg/plist/plist.go:111) wraps the parse error as "invalid date value: %w". This surfaces from any xml.Unmarshal / DecodeElement call that decodes a plist Value containing a malformed <date>.

Source

Thrown at pkg/plist/plist.go:111

		if err := dec.DecodeElement(&txt, &start); err != nil {
			return err
		}
		// remove all whitespace/newlines from base64 text
		b64 := strings.Join(strings.Fields(txt), "")
		db, err := base64.StdEncoding.DecodeString(b64)
		if err != nil {
			return fmt.Errorf("invalid base64 data: %w", err)
		}
		v.Data = db
		return nil
	case "date":
		var txt string
		if err := dec.DecodeElement(&txt, &start); err != nil {
			return err
		}
		t, err := time.Parse(time.RFC3339, strings.TrimSpace(txt))
		if err != nil {
			return fmt.Errorf("invalid date value: %w", err)
		}
		v.Date = &t
		return nil
	case "true":
		b := true
		v.Boolean = &b
		// consume tokens until matching end element
		return dec.Skip()
	case "false":
		b := false
		v.Boolean = &b
		// consume tokens until matching end element
		return dec.Skip()
	case "real":
		var txt string
		if err := dec.DecodeElement(&txt, &start); err != nil {
			return err
		}

View on GitHub (pinned to dd909d0973)

Solutions

1. Convert the <date> text to RFC3339 before parsing, e.g. replace the space with 'T' and ensure a timezone offset like '+0000' or 'Z' is present
2. Pre-validate the date text with time.Parse(time.RFC3339, strings.TrimSpace(txt)) in your own code and emit a clearer error with the offending value
3. Fix the source plist so it uses RFC3339, e.g. <date>2026-09-01T12:00:00Z</date>
4. If you control the parser, parse plist dates with a dedicated layout ("2006-01-02 15:04:05 -0700") as a fallback before failing

Example fix

// before (fails)
<date>2026-09-01 12:00:00 +0000</date>
// after (RFC3339)
<date>2026-09-01T12:00:00Z</date>

func validPlistDate(txt string) error {
	_, err := time.Parse(time.RFC3339, strings.TrimSpace(txt))
	return err
}

var v plist.Value
if err := xml.Unmarshal(data, &v); err != nil {
	var perr *time.ParseError
	if errors.As(err, &perr) && strings.Contains(err.Error(), "invalid date value") {
		// handle malformed <date>: normalize to RFC3339 or skip
	}
	return err
}

When it happens

Trigger: xml.Unmarshal (or xml.NewDecoder.DecodeElement) on a plist document whose <date> element text does not parse as RFC3339, e.g. plist macOS-style dates like "2026-09-01 12:00:00 +0000" (space separator, no T), missing timezone, or "Fri Sep 1 12:00:00 2026".

Common situations: Hand-edited or tool-generated plists copied from macOS `defaults export` output, which uses a different date format than RFC3339; timestamps with a space instead of 'T'; dates missing the mandatory timezone offset; template files with placeholder dates.

Related errors

• failed to unmarshal xml: %w
• unexpected plist format: missing root dict
• invalid real value: %w
• invalid integer value: %w
• failed to unmarshal line %#q: %w

AI-assisted analysis of lima-vm/lima@dd909d0973 (2026-09-01). Data as JSON: /api/errors/1e99f5ba63dfa1e6. Report an issue: GitHub.