Open World Cup 2026 fixtures in South African Standard Time

punts — Sun, 31 May 2026 17:58:45 +0000

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.

Building a Slot-Machine Picker Without Making Gambling Claims

punts — Sat, 23 May 2026 09:39:57 +0000

A small open-source HTML/CSS widget that links to a live random casino game picker with responsible-
gambling guardrails.

Post:

I built a small open-source widget for a larger web tool: a random casino game picker for
CasinoGaming.co.za.

The goal was simple: make game discovery feel like a slot-machine spin, while being careful not to
imply that the tool predicts outcomes, improves odds, or recommends a deposit.

Live picker:
https://www.casinogaming.co.za/random-casino-game-picker-south-africa/

GitHub repo:
https://github.com/puntsza-web/random-casino-game-picker

GitHub Pages demo:
https://puntsza-web.github.io/random-casino-game-picker/

## The Product Constraint

Casino interfaces can get noisy fast. A random picker sounds fun, but the wording matters because a
So the tool had a few hard rules:

It is a discovery tool, not a prediction tool.
It links to game guides, not directly to a deposit action.
It keeps 18+ and responsible-gambling notes visible.
It avoids certainty language, prediction language, and deposit-push language.
It shows practical context such as RTP, volatility, caution notes, and availability checks.

## The Embeddable Card

The open-source repo is intentionally small. It is just HTML and CSS, with no build step, so
publishers can drop a card into an article or resource page.

The card uses a single component namespace so it is less likely to collide with the host page. The
reel tiles are decorative, so they are hidden from assistive technology. That keeps the screen-
reader path focused on the actual action: the link to the live picker.

## The Live Tool

The full page has a slot-machine UI, category filters, shareable result URLs, a share-card download,
and a copyable credit section for anyone who wants to reference the tool.

DEV Community: punts