mirror of
https://github.com/jwoglom/tconnectsync.git
synced 2026-08-24 10:14:36 -05:00
xannasavinandJames Woglom
758204d4de
arrow's isoformat() ends a timestamp with its UTC offset, e.g. '2026-07-16T00:00:00+02:00'. Placed raw into a query string, '+' is a reserved character that servers decode as a space, so Nightscout receives '2026-07-16T00:00:00 02:00' and answers 'could not parse as a valid ISO-8601 date'. Any user on a positive UTC offset hits this on every date-filtered query. The current workaround retries the request with 'T' replaced by a space (t_to_space) and treats a failure as 'no previous entry'. That gets a response, but it works around the symptom: the value is still mangled, every affected query costs two round-trips, and a genuinely empty result is indistinguishable from a rejected one. Percent-encoding the value fixes the cause: the offset survives, the first request succeeds, and the t_to_space fallback and its retry wrapper are no longer needed and are removed. Adds tests for time_range(): that a positive offset is encoded rather than emitted raw, that the encoded value round-trips back to the original instant, that negative offsets and 'Z' still parse, and the bounds/no-bounds cases. There was no coverage of time_range() before. The encoding test fails on master with '+' present in the query and passes with this change. Running with this in my EU deployment since May.