Selector families and target resolution

One target strategy per request

TimeLogic API resolves time targets through four selector families: `tz`, `ip`, `lat` + `lon`, or `offset`. The public docs should make that explicit because mixing selector families creates ambiguity and usually signals an integration bug upstream.

The cleanest production pattern is to normalize on a single canonical selector family in your own app, then use the others only for ingestion or fallback workflows.

• Use `tz` when your system already stores IANA timezone names.
• Use `ip` when you are resolving an end user before you have profile settings.
• Use coordinates when geography exists but a timezone label does not.
• Use `offset` only when a fixed UTC offset is truly what you mean.

Wall-clock timestamps need context

Routes that accept ISO input can interpret local wall-clock times when you pair the timestamp with a source timezone field. Without that context, an ISO string without an explicit offset is not enough to reconstruct the intended instant.

That rule matters most in conversion, elapsed-time, and diff workflows where business logic depends on exact instant boundaries rather than display output.