UTC-only timestamps versus offset-aware strings for DST‑safe regional queries in CouchDB

The goal is to choose a timestamp representation that lets a CouchDB view return the correct set of documents for a user‑specified local‑time range, even when that range spans an ambiguous hour during a daylight‑saving transition.

CouchDB stores timestamps as JSON strings; map/reduce views run SpiderMonkey JavaScript, where new Date() parses ISO 8601 strings and converts them to UTC, discarding the original offset. Consequently, UTC‑suffixed strings sort lexicographically in chronological order, while offset‑aware strings do not, and the view server lacks an IANA time‑zone database to resolve names like Europe/Berlin.

The unresolved decision is whether to store all timestamps in UTC and let the application convert user times before querying, or to keep the original offset in the string and add a secondary sort key or collation function, so that a single view query can correctly handle ambiguous local intervals without the application needing to split the request.

Which representation guarantees that a view key range query returns exactly the documents whose timestamps fall inside the user‑specified local interval across DST boundaries? Does preserving the offset and adding a sortable UTC copy provide a simpler, more maintainable solution than relying on the application to split ambiguous queries?