Difference of latest dates. #541
|
I'm a bit puzzled. My app follows UTC time. I know this API doesn't follow UTC time, but I got this recently: for https://api.frankfurter.dev/v2/rates?base=USD I see the dates as 2026-07-03, but for https://api.frankfurter.dev/v2/rates?base=USD&from=2026-07-01 I see rates showing 2026-07-04... Which is it? which is the latest one? |
Replies: 3 comments 2 replies
|
Good catch, and sorry for the confusion. Two things are going on here, one of which was a real bug on our side. First, the API clock is UTC. An open-ended query ("latest", or Second, the inconsistency you saw was a CDN caching bug. Those forward-dated rows only enter scope once the UTC date rolls over to 2026-07-04, but our cache was only purged when new data arrived, not at midnight. Your As for "which is the latest": trust the |
|
This might be a bug as well: Notice the rate difference |
|
We have opened pull request #544 to cap the WeightedAverage reference date at Date.today. This ensures todays rates maintain full weight (age 0) even when tomorrows rates are present in the snapshot, resolving the discrepancy between latest and range queries. |
Good catch, and sorry for the confusion. Two things are going on here, one of which was a real bug on our side.
First, the API clock is UTC. An open-ended query ("latest", or
from=withoutto=) is anchored on the current UTC date. What is not UTC-aligned is the data itself: thedateon each record is the observation date the source published, in its own local business calendar. With 80+ sources across timezones, a latest snapshot legitimately mixes dates. A few central banks even publish their official rate dated the next day (for example Georgia and Kyrgyzstan), so rates dated 2026-07-04 existed in the database on Friday afternoon.Second, the inconsistency you saw was a CDN caching bug.…