A useful time-zone input must identify a rule set, not merely display a familiar three-letter label. Named IANA zones provide that durable link.
Abbreviations are not unique
The same abbreviation may be used for unrelated zones, and the letters shown can change between standard and daylight time. CST is a familiar example because it can refer to different parts of the world. Without a country, city, date, and convention, software cannot reliably turn those letters into one ruleset or one instant.
A named zone carries history
An identifier such as America/New_York or Asia/Kolkata points to rules that can vary by date. It is not just a prettier spelling of a fixed offset. The database can resolve historical and scheduled transitions, so the same zone name remains meaningful when its offset changes. That is why calendars and APIs should store zone identifiers alongside local event times.
Choose by place, display the details
A zone picker should let people search readable place names and the exact identifier. The selected value should remain visible together with its current offset, while the calculation uses the full identifier on the server. Device detection can suggest a starting option, but it should never lock the user in or replace an explicit choice.