Having a look at the dropdown - the cities list definitely comes "as is" from the UNIX zoneinfo system, which does not contain all cities that exist.
I don't think that expanding the list is a good idea, because zoneinfo is an operating system layer thing, and for maintainability, you really don't want to go adding your own list. It gets very messy doing that because DST start-end times are attached to that zone list.
I do think that:
The current zone offset should be added a prefix to the list entries (and the entries sorted by that zone offset, and any zones currently having DST should have a postfix indicator of that as well)
Either:
Entries should be added for fixed-from-GMT offset at 30 minute intervals (and these should not have DST ever)
Or there should be support for simply entering your own GMT offset, and that should also not have DST ever.
If you need to do DST, then you need to know specify what actual zone you're in, because the zoneinfo data keeps track of the various changes that can happen to DST start and end times. Either that or we wind up supporting entry of DST start-end... which is just a recipe for nightmares and badness. Zoneinfo keeps that data already... and for good reason, it should not be reimplemented.
no subject
I don't think that expanding the list is a good idea, because zoneinfo is an operating system layer thing, and for maintainability, you really don't want to go adding your own list. It gets very messy doing that because DST start-end times are attached to that zone list.
I do think that:
The current zone offset should be added a prefix to the list entries (and the entries sorted by that zone offset, and any zones currently having DST should have a postfix indicator of that as well)
Either:
Entries should be added for fixed-from-GMT offset at 30 minute intervals (and these should not have DST ever)
Or there should be support for simply entering your own GMT offset, and that should also not have DST ever.
If you need to do DST, then you need to know specify what actual zone you're in, because the zoneinfo data keeps track of the various changes that can happen to DST start and end times. Either that or we wind up supporting entry of DST start-end... which is just a recipe for nightmares and badness. Zoneinfo keeps that data already... and for good reason, it should not be reimplemented.