🌟 Add Start/End Times to Individual Tickets

[creativeindustriesgroup]

Description:

Currently, an event's start and end times are only defined at the top-level event level.

This means that if the (theatre) event happens several times over several days, the start date gets set to the start time of the first day and the end date gets set to the end time of the last date. However, if there are multiple performances in a day or if the performances are not all at the same time, this becomes a problem.

This proposal is to add start and end time fields directly to each ticket in the ticket configuration.

Proposed Changes:

Ticket Configuration

• Add start_time and end_time fields to each ticket’s configuration.
• These would be set by the promoter when creating or editing tickets.

API Updates

• Include start_time and end_time in the Tickets Information API.
• Keep existing event-level start/end times but calculate them automatically based on the tickets start/end dates rather than requiring separate manual input.
• This feature will not remove or replace the existing event-level start/end times - it will add granularity without breaking existing integrations.

** UI Updates **

• The input fields for event dates can be removed from the top-level event config as they are now automatically calculated from the ticket data
• The tickets can now display the more accurate event start times
• Ticket configuration gets new start/end time fields
• Additional Suggestion: The top-level event config can contain an "estimated event duration" time. This way, the event end time can automatically be calculated for each ticket, further increasing ease-of-use.

Benefits:

• Google Structured Data Compliance: Google recommends treating tickets across multiple dates as separate events. It would be possible to create structured data like this based on ticket start/end times without having to physically create multiple events.
• Improved User Experience: Buyers can clearly see the exact time their ticket is valid for, avoiding confusion for multi-day or multi-time events.
• Reduced Promoter Workload: Eliminates the need for promoters to duplicate events just to offer tickets at different times for the same overall event

Example Scenario:

• A theatre festival runs for 3 weeks, with multiple performances each day.
• With this feature, promoters can sell tickets for specific days and times without creating separate events for each showing.

Current Implementation Example:

Event: "Shakespeare in the Park" Performances:

• June 1, 14:00
• June 1, 19:00
• June 3, 15:00
• June 10, 14:00

Event API Response (current)

{
  "event_id": 123,
  "name": "Shakespeare in the Park",
  "start_time": "2025-06-01T14:00:00Z",
  "end_time": "2025-06-10T16:30:00Z",
  "tickets": [
    { "ticket_id": 1, "name": "June 1, 14:00" },
    { "ticket_id": 2, "name": "June 1, 19:00" },
    { "ticket_id": 2, "name": "June 3, 15:00" },
    { "ticket_id": 2, "name": "June 10, 14:00" }
  ]
}

Issue: Start time shows first performance only, end time shows last performance only. No granularity for different ticket times.

Proposed Implementation Example:

{
  "event_id": 123,
  "name": "Shakespeare in the Park",
  "start_time": "2025-06-01T14:00:00Z", 
  "end_time": "2025-06-10T16:30:00Z", 
  "tickets": [
    { 
      "ticket_id": 1,
      "name": "June 1 Matinee",
      "start_time": "2025-06-01T14:00:00Z",
      "end_time": "2025-06-01T16:30:00Z"
    },
    { 
      "ticket_id": 2,
      "name": "June 1 Evening",
      "start_time": "2025-06-01T19:00:00Z",
      "end_time": "2025-06-01T21:30:00Z"
    },
    { 
      "ticket_id": 3,
      "name": "June 3 Matinee",
      "start_time": "2025-06-03T15:00:00Z",
      "end_time": "2025-06-03T17:30:00Z"
    },
    { 
      "ticket_id": 4,
      "name": "June 10 Matinee",
      "start_time": "2025-06-10T14:00:00Z",
      "end_time": "2025-06-10T16:30:00Z"
    }
  ]
}

Benefit: Each ticket now carries its own start and end time, allowing clear communication to buyers, easier structured data generation, and reduced need for duplicate events.

---

Additional Suggestions:

• Consider updating the /api/events/{id} (authenticated route) to return the same expanded ticket and image data as /api/public/events/{id}. This would make ticket management more consistent and reduce redundant API calls for authenticated users.

Related Endpoints:

• /api/public/events/{id} — already returns ticket + image data.
• /api/events/{id} — should be updated to include the same.

[daveearley]

Thanks for the detailed proposal, @creativeindustriesgroup! This is something I've been thinking about and planning for some time. It falls into the same area as recurring events

It will behave similarly to what you've described above, except will be more full-featured in order to support more complex setups, including multi-day events, recurring series etc.

We'll be introducing a normalized structure where each distinct instance of an event (e.g. Aug 5 @ 7PM, Aug 12 @ 7PM) is stored in a new event_occurrences table. This gives us a single source of truth for date/time and allows orders, attendees, tickets, check-ins, and reporting to link to specific occurrences.

Still very much WIP, but that's the plan as of now