Iteration date boundary shifts when UI local dates convert to UTC storage

Iteration date boundary ambiguity

Azure DevOps stores work-item and audit dates in UTC, yet the web portal renders iteration start and end dates using each user's browser time zone. When a team member sets an iteration boundary in the UI, the date is treated as a local calendar day and converted to UTC for storage. REST API callers that supply naive date strings or explicit UTC timestamps can produce a different stored instant, shifting the effective boundary by up to one day across DST transitions or time-zone offsets.

Constraints and uncertainty

No organization-level time-zone override exists to force a single display zone. Queries and dashboards filter against UTC-stored values, so local-date filters near midnight may include or exclude items unexpectedly. The exact conversion rule the UI applies—whether it assumes local midnight, UTC midnight, or another anchor—is not documented in a single authoritative source.

What conversion anchor does the UI use when persisting an iteration start or end date entered as a date-only value? How should API consumers format date-only iteration boundaries to guarantee the same stored instant regardless of the caller's time zone? Is there a supported pattern to query iteration work items by local calendar date without UTC midnight edge cases?