On-time rate without integer division

Constraints

1. 1On time is minutes <= 30. The boundary is inclusive, and four deliveries sit exactly on it, so an accidental < changes three of the four answers.
2. 2on_time_pct is a percentage between 0 and 100, not a fraction between 0 and 1.
3. 3Both operands are integers, and integer division truncates towards zero on this engine — 6 / 9 is 0, not 0.667. Force decimal arithmetic before the division happens, not after.
4. 4Round to one decimal place.
5. 5No city has zero deliveries here, but say in your own head what you would add if one could — the division would be by zero.
6. 6Order by city.

Worked example

Bengaluru: 9 deliveries, 6 of them at 30 minutes or less. 6 / 9 in integer arithmetic is 0 — the fractional part is discarded, and no error is raised. 100.0 * 6 / 9 is 66.7, because the first operand is a decimal literal, which promotes the whole expression to decimal arithmetic before any division happens. Order matters. 100 * (6 / 9) still truncates first and gives 0; ROUND(6 / 9, 1) * 100 does too. The decimal has to enter the expression before the division, not after it.

What this tests

The integer-division trap, which silently floors a rate to zero, plus conditional aggregation for the numerator.