If you have ever tried to build anything around a major football tournament from South Africa, you already know the pain: every published schedule seems to live in a different time zone. Match listings come in UTC, in the host country's local time, or in some broadcaster's preferred zone, and almost none of them are in South African Standard Time (SAST, UTC+2). So before you can render a single fixture, you are stuck writing fragile offset math and second-guessing daylight-saving edge cases that do not even apply to SAST but absolutely apply to the source data.
Why SAST fixture data is annoying
The core problem is that fixtures for the 2026 World Cup are spread across multiple North American host cities, each in its own zone, several of which observe daylight saving time. Converting those kickoff times into a clean, consistent SAST value means tracking each venue's offset on each date, then normalizing everything to UTC+2. It is the kind of tedious, error-prone work that quietly breaks a calendar widget or a reminder feature, usually right before kickoff.
What Edges published
To take that conversion burden off developers, Edges put together an open dataset of every 2026 World Cup fixture, pre-converted to SAST. You can browse it here:
World Cup 2026 fixtures dataset
The dataset is plain, machine-readable, and offered in two formats so you can drop it straight into whatever you are building:
- CSV: wc2026-fixtures.csv
- JSON: wc2026-fixtures.json
How developers can use the CSV/JSON
The JSON is the easiest starting point for a JavaScript project. A minimal fetch looks like this:
const res = await fetch("https://www.edges.co.za/data/wc2026-fixtures.json");
const fixtures = await res.json();
// Already in SAST, so no offset math needed
const upcoming = fixtures
.filter(f => new Date(f.kickoff_sast) > new Date())
.sort((a, b) => new Date(a.kickoff_sast) - new Date(b.kickoff_sast));
console.table(upcoming.slice(0, 5));
Because the times are already normalized to SAST, you skip the conversion layer entirely and go straight to filtering, sorting, and rendering. The CSV is just as handy if you would rather pull the data into a spreadsheet, a quick pandas script, or a static-site build step. Both files share the same fields, so you can switch formats without rewriting your parsing logic.
Why the dataset deliberately excludes odds and predictions
This is a fixtures dataset, and nothing more. It deliberately leaves out betting odds, model predictions, and any kind of forecast. That is a design decision, not an oversight. Mixing scheduling data with odds tends to blur the line between a neutral reference and a betting product, and it nudges projects toward territory that carries real responsibilities. Keeping the dataset to dates, venues, teams, and SAST kickoff times means it stays a clean, dependable source you can build on without inheriting any of that baggage.
If your project does touch betting in any way, please keep it strictly 18+ and point users toward support resources, such as this responsible gambling page.
Wrapping up
The whole idea here is boring in the best way: accurate fixtures, already in SAST, in formats you can consume in a few lines of code. Grab the CSV or JSON, wire it into your app, and spend your time on the features that matter instead of fighting time-zone math.
Top comments (0)