cmd line accept timezone abbreviations

[26labs]

It is tedious and error prone to enter full names. For most people using timezones regulalry we will remember the most used zone abbreviations e.g. AEDT instead of australia/sydney or CST instead of america/los_angeles

[oz]

Thanks for opening an issue here. 😄

I don't plan to work on this personally, but this is an interesting improvement and similar issues exist to try to make time zone selection and discovery less annoying (c.f. #30).

As always, contributions are welcome. If you'd like to see that feature sooner than later, please post a comment, and let people know what you're up to! 🙇🏻

[jnd-au]

Timezone abbreviations are not unique, for example IST could be Israel +02:00 or India +05:30. And for such overlaps, the “ST” abbreviation can mean at least two opposite things: either Standard Time (no daylight saving) or Summer Time (with daylight saving). Potential workarounds: (a) tz aborts and shows the ambiguous options with their numerical offsets and full names, so that the user to re-try with the full unique name (b) tz shows an interactive menu and the user is required to choose between the options (c) tz would show all distinct variations.

So, the problem has some solutions, but they add complexity. I know it would be a useful feature, e.g. if a user is told that an event is happening in “EST” they might want to interrogate tz. However, people also use informal abbreviations like “ET” (as a USA shorthand for EST/EDT) so it would be hard to support all real-world abbreviations.

Also, if people can use the abbreviations on the command line then they’ll expect to use them for configuring tz’s TZ_LIST. However, an abbreviation like AEDT is bad for TZ_LIST because it’s incorrect for half the year (because “Australia/Sydney” swaps between “AEST” and “AEDT” during the year), so users should not use these abbreviations. So, tz would probably need to have different logic to accept abbreviations interactively while forbidding abbreviations in TZ_LIST.