fx-rates-correctnesslisted

# FX rates correctness Exchange-rate bugs rarely throw. They return a plausible number that is wrong — a Friday rate silently used for Sunday, a JPY amount rounded like EUR, a backtest joining Tokyo closes against a CET fix. This skill catalogs the failure modes and the code patterns that avoid them. Examples use exchangerate.dev (keyless, `https://api.exchangerate.dev`), but the pitfalls apply to any FX source. ## 1. There is no rate for Saturday FX reference rates (ECB, FRED) publish on **business days only**. Two different API behaviors exist, and confusing them corrupts data: - **Snapshot endpoints forward-fill.** `GET /v1/2024-01-14?base=USD&symbols=EUR` (a Sunday) returns Friday's fix with `"is_forward_filled": true` and `data_updated_at` pointing at the Friday. If you store this row keyed by the Sunday date without checking the flag, your database now claims a Sunday fix existed. - **Range endpoints omit.** `GET /v1/range?...` returns business days only — weekends are **absent rows, not nulls**. A naive "365 rows per year" assumption breaks; so does positional alignment against a calendar array. Pattern: ```python row = get_historical("2024-01-14", base="USD", symbols=["EUR"]) if row["is_forward_filled"]: # The requested date had no published fix. Decide explicitly: # - display/UX: fine to show, but label it ("as of Fri 2024-01-12") # - accounting/audit: use data_updated_at's date as the rate date, not the requested date # - research: usually bett