Re: User-Friendly TimeZone List

On Aug 15, 2007, at 13:27 , Naz Gassiep wrote:

> Hi all,
>    I am still, after quite some time, wrangling over the time zone
> system in my app. I have sorted out all the internal handling,
> however I am still uncertain as to what the best way to get the
> user to select their time zone is.
>
>    I was thinking of having users just select their timezones from
> a list which was populated with the contents of the query:
>     select * from pg_timezone_names ;
> which would look something like this.
>     http://mrnaz.com/tztest.html
>
> This however is problematic for a number of reasons:
>
> 1. The timezone list there isn't exactly user friendly, there are
> many Etc/* timezones there, as well as others that would be
> potentially confusing for users who are trying to select the
> timezone they are in.
> 2. If a timezone is removed from the list for whatever reason, then
> the system will be left with users who have selected a timezone
> that is no longer a valid choice in the list.
>
>    The ideal situation would be to maintain my own persistent list
> of timezones (the way Microsoft maintains their own user-friendly
> list that they use for Windows) that maps to the timezones embedded
> in the PG back end, but I haven't the resources to pull this off.
> Has anyone else worked on a mechanism to allow users to supply the
> timezone they are in, and if so, do you have any comments on how
> best to handle the apparently mutually exclusive problems of
> simplicity for users and accuracy in the back end?
>
>    At the simple end of the I can't just have users only select
> from a list going from GMT-12 to GMT+12. At the complex end of the
> scale I'd just give them the output from the list and any that are
> deprecated will result in the user reverting to UTC until they
> reset a new timezone.

Don't forget that not all timezones are offset by integer hours from
GMT. I, too, am battling timezone handling- I have been using various
Perl modules to fill in the missing components such as better/multi-
lingual timestamp parsing.

Cheers,
M