How we build daily gold price data

1. What “a day” means here

Historical daily pages and the month table use a UTC calendar day key (YYYY-MM-DD). That day runs from 00:00 UTC to 23:59:59.999 UTC. If you are not in UTC, the label on the page may differ from your local date for the same physical moment in the market.

2. Where daily OHLC numbers come from

Month tables, month charts, and each daily URL under /gold-price/… read from our daily snapshot store (one row per currency and UTC day). Each row holds open, high, low, and close for 24K gold in USD per troy ounce. Per-gram and lower-karat columns on the site are derived from that 24K/oz basis using 31.1035 grams per troy ounce and the same purity ratios used across calculators.

Rows are created or updated by automated jobs (typically aligned to UTC) and by controlled backfills when we need to repair gaps. The database may record a short source label on a row (for example reference market data, an API snapshot, or values derived from same-day intraday snapshots).

3. Source hierarchy (without binding to one vendor)

We use a layered model so expectations stay clear even when upstream products change:

1. Live calculators and tables (homepage, per-gram tools, karat pages): a spot-style snapshot pipeline from third-party precious-metal quote APIs, tuned for freshness.
2. Daily history (/gold-price/…): a separate UTC archive built from stored daily OHLC rows. It is optimized for a stable one number per UTC day, not for tick-by-tick streaming.
3. Repairs: when ingestion fails, we may insert or replace a daily row using the same UTC rules, including CSV or migration imports flagged in the row's source field.

4. Storage you can reason about (verification)

Public daily OHLC lives in a dedicated relational table (internally keyed by currency + UTC day) with open/high/low/close in USD per troy ounce for 24K, plus a source string and row timestamps. Anonymous site visitors may read these rows where our Supabase policies allow; writes are restricted to our automation/service role so the archive cannot be crowd-edited.

A missing day in the month list means no row for that UTC date—not a hidden zero price. That usually tracks thin markets, holidays, or gaps in our capture window, and is different from a venue-specific “session closed” banner.

5. How this differs from the “live” calculator

The homepage and many calculators show a current spot-style snapshot from our live price pipeline (third-party precious-metal APIs). That feed is optimized for now. A historical daily page is an archived summary for one UTC day and will not always match another vendor’s “close” for your local session.

6. Known limitations (honest expectations)

• Weekends and holidays: There may be no row for a calendar day when markets are thin or our pipeline did not record one.
• Vendor differences: “Daily high/low/close” depends on data provider and session definition; another site can legitimately differ slightly.
• Revisions: We may insert or replace a daily row when we fix ingestion errors; the goal is factual accuracy, not immutability for every past print-out.

7. Currency scope today (and later)

Today: the daily archive and on-page OHLC we describe here are built around USD and a 24K troy-ounce basis. Other units you see on tool pages (grams, pennyweight, pounds) are mathematical conversions from that same metal price, not separate spot markets per unit.

Future: if we add more settlement currencies or parallel archives, we will name them explicitly on this page and in the disclosure blocks so rows never silently change meaning.

8. Not advice

All numbers are for information and tooling only. Nothing on MyGoldCalc is personalized investment, tax, or trading advice. Always verify prices with your counterparty before you buy or sell.

9. Changelog (high level)

• 2026-05-10: Expanded public methodology: UTC day definition, live vs daily archive, source hierarchy, multi-currency scope, operational metadata, FAQ/HowTo structured data.
• 2026-04-30: Introduced dedicated daily OHLC storage (per UTC day) separate from realtime snapshot rows; automated writes and CSV backfills documented.