One Line of Date Parsing Made Every Region Look Normal

On 7 August we published a correction retracting seven regional drought percentages that had gone out to subscribers. Those figures came from a step function of the Oceanic Niño Index with no rainfall data in it at all.

In the same post we said something less comfortable: the observed rainfall feed we were checking them against could not be trusted either. Every region read NEAR NORMAL, including one at −94 percent and one at +16,142 percent. We flagged the panel as under repair and promised the diagnosis. This is it, along with the numbers the feed now produces.

The Line

ClimateSERV returns dates as MM/DD/YYYY. Our worker extracted the month like this:

const m = p.length===3 && parseInt(p[0])<=31 ? parseInt(p[1])-1 : parseInt(p[0])-1;

Read the guard. Months are 1 to 12, so parseInt(p[0]) <= 31 is true for every month there is. The condition can never be false. So the expression always takes the first branch and returns p[1], which is the day.

For 06/30/2026 it computed month index 29. For 05/30/2026 it also computed 29, because both fall on the 30th.

What That Did to the Baseline

The code then gathered "all other granules in the same month" to average as a climatology. But since the month had become the day number, "same month" meant "same day number".

The request window was about 61 days, 1 May to 30 June 2026. Across 61 days there is exactly one other granule numbered 30: 30 May.

IAMElNino.com analysis. So the field labelled climatology_mm held the rainfall on a single day, one month earlier. The "anomaly" was 30 June minus 30 May. We reconstructed the series and ran the worker's own expression against it, and it reproduces every published figure exactly: +0.5, +4.9, −4.9, −0.6, +1.5, +2.6, −4.0 and −2.4 mm.

Three consequences followed, and together they explain everything readers were seeing.

• The percentages were divisions by one day. Northern China's 30 May reading was near zero, so 4.9 mm over roughly 0.03 mm produced +16,142 percent.
• Every label said NEAR NORMAL. The thresholds were ±10, 25 and 50 mm, sized for monthly totals. A one-day difference almost never clears 10 mm, so everything landed in the middle bucket regardless of what the number was.
• The values were daily, not monthly. Which is also where we got the diagnosis wrong the first time. The 7 August post called the magnitudes "implausible as monthly totals". They were not implausible, they were daily. India at 7 mm in a day during the monsoon is entirely normal. That post now carries a dated correction.

The Fix We Nearly Shipped

The obvious repair is to ask ClimateSERV for monthly sums instead of daily averages. We wrote that patch: change intervaltype from 0 to 1, and operationtype from 5 to 4.

Before deploying it we tested the parameters against the live API. That patch would have broken the feed completely.

IAMElNino.com analysis, from live calls to the ClimateSERV API on 9 August 2026 between roughly 14:00 and 14:30 UTC, using a one-degree test polygon and a January to March 2024 window. For CHIRPS, the only combination that returns data is daily granules with a spatial average. Ask for a sum and ClimateSERV returns an empty array with progress 100 and no error. Ask for monthly and it does the same.

ClimateSERV's own documentation lists operation type 4 as "Sum" in its getParameterTypes response. For CHIRPS it does not honour it. The interval enumeration is not documented at all: the docs say it is "hardcoded in the mark up language of the current client".

Had we deployed that patch, the parser would have thrown "Empty data response" for every region, the feed would have gone dark, and we would have published a post saying it was repaired. The test took ten minutes.

What the Rebuilt Feed Does

The aggregation had to move into our worker rather than the request. Each granule is the spatial mean rainfall for one day in mm, so summing across a calendar month gives the monthly areal-mean total. The baseline comes from the same calendar month in prior years, fetched as separate requests and cached unless the source dataset or processing method changes.

• Dates are parsed positionally. No guessing.
• A month is only used if it is complete. The day count must equal the length of the month, so a partial month can never be cached as a total.
• No anomaly is published on fewer than five baseline years. The region reads INSUFFICIENT BASELINE instead. This is the state the old code faked.
• No percentage against a baseline below 5 mm. The millimetre anomaly is still published. This is what stops another +16,142 percent.
• Labels are percent-of-normal, so they work at any accumulation window rather than assuming monthly millimetres.
• The payload states its own method, baseline length and observation period, so the dashboard cannot misdescribe it again.

Before and After

Same eight regions, same day, same underlying CHIRPS rainfall product, which combines satellite estimates with station observations. The left side is what the site served on the morning of 9 August. The right side is what it serves now.

India is the clearest illustration of why nobody caught this. Seven against seven looks like a reading. It was one day against one day, and the fact that they nearly matched made it look like a region sitting comfortably at its normal. The real comparison is 98 mm of June rain against a 116.4 mm June average across ten years, 2016 to 2025.

Southern Africa illustrates why the new percentage guard matters. Its June baseline is only 6.9 mm, because June is deep in its dry season, so even a small absolute difference can produce a large percentage anomaly. It now returns +31 percent, a sensible statement about a dry month that was slightly wetter than usual. The earlier +16,142 percent occurred in Northern China, where the broken one-day baseline was approximately 0.03 mm.

What the Numbers Actually Say

Three regions show deficits exceeding 20 percent for June 2026: Indonesia and Southeast Asia at 21 percent below its ten-year June average, the Peru and Ecuador coast at 29 percent below, and East Africa at 32 percent below its seven-year average. Peru is worth noting because it is the site's designated flood region: the canonical El Niño signal on that coast is heavy rainfall, not dryness. India, Northern China and Northeast Brazil also sit modestly negative, between 8 and 15 percent below average.

Set against the alert we retracted, the picture is close to inverted. India was emailed at 78 percent drought risk and is 15 percent below normal, which is unremarkable. Southern Africa was emailed at 65 percent and came in wetter than usual. Indonesia and Southeast Asia was emailed at 80 percent and is the one large region genuinely dry, at −21 percent, which the ladder got right by accident rather than by measurement.

One caution on all of it. June is a single month, and for several of these regions it is not the month that matters. Southern Africa's rains do not begin until October, so a June reading there says almost nothing about the season FEWS NET is actually worried about. A monthly anomaly is an observation, not a seasonal outlook.

What to Watch

• The observation period on each region. It is stated in the payload. If they diverge, some regions are staler than others.
• Regions reading INSUFFICIENT BASELINE. That is the honest state, not a failure. It means fewer than five years of that calendar month are available.
• Peru and Ecuador. The June deficit is worth tracking, but it is not evidence against a later El Niño flood response. Coastal rainfall there is strongly seasonal, and a single monthly anomaly has little predictive value for the coming warm season.
• Southern Africa from October. That is when its rainy season starts and when the FEWS NET projection becomes testable.

The Short Version

A guard clause that could never be false made a date parser read the day as the month. That turned a climatology into a single earlier day, turned percentages into divisions by near-zero, and pushed every region into the same label because the thresholds assumed a different unit. None of it threw an error, which is why it survived.

The repair is deployed and all eight regions now report monthly totals against a real multi-year baseline. We also nearly shipped a fix that would have silently emptied the feed, and only caught it because we tested the API parameters instead of trusting the documentation. That is the more useful lesson of the two.