Show event times in a guest's timezone

[KalebCole]

User scenario

I am visiting New York while my friends plan events in Seattle. I need a clear view of when each Partiful event starts and ends where I am, so I do not RSVP based on a Pacific-time assumption.

Problem

The CLI accepts --timezone when creating or RSVPing, and event output carries timestamps, but it does not provide an explicit guest-facing conversion view. Reading ISO timestamps or manually converting every item is error-prone, especially across daylight-saving changes.

Proposed experience

partiful events list --timezone America/New_York
partiful events get <eventId> --timezone Europe/London
partiful events list --timezone America/New_York --format json

Human output shows the event's source timezone when known plus a labeled local start and end time in the requested IANA timezone. JSON output preserves raw source timestamps and adds explicit requested-zone renderings and conversion metadata, never replacing the raw values. Invalid zones fail before network mutation.

Scope boundaries

This is read-only presentation, not calendar sync, travel booking, or a change to the event's scheduled time. Do not infer a guest's location or silently use device locale for agents; callers must pass a zone or receive the documented default.

Discovery needed

Verified repo facts: create/RSVP schemas accept IANA timezones; README documents an America/Los_Angeles default; event list exposes ISO startDate and endDate. Unknown: which Partiful event fields reliably retain the organizer's intended timezone versus normalized instants. Verify source timezone availability and daylight-saving handling; when absent, clearly label the rendering as a conversion from a timestamp rather than claiming organizer-local time.

Acceptance criteria

• Requested valid IANA zones render start and end correctly across daylight-saving boundaries.
• JSON retains raw timestamps and provides stable, labeled conversion fields and the requested zone.
• Missing end times and missing source-zone metadata have explicit null/unknown behavior.
• Empty event lists succeed with the selected timezone reflected in metadata.
• Invalid timezone input and malformed source timestamps return structured validation/data errors.
• Tests cover multiple zones, DST transitions, null end dates, invalid zones, and JSON output.

Related work

#19 covered Google Calendar sync, whereas this is a direct CLI read experience with no external calendar connection. #29 improved date parsing for writes; this addresses reliable display for traveling guests. #68 documents RSVP semantics, not time conversion.