User-Friendly TimeZone List
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.
Comments on this usability problem are appreciated,
- Naz.
On 8/15/07, Naz Gassiep <naz@mira.net> 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.htmlThis 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.
Do the views in 8.2 pg_timezone_abbrevs and pg_timezone_names help at all?
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.htmlThis 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
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<!----><br>
<blockquote
cite="mid:dcc563d10708151044m3b39d542k4d43ae59b44dcda6@mail.gmail.com"
type="cite">
<pre wrap="">Do the views in 8.2 pg_timezone_abbrevs and pg_timezone_names help at all?</pre>
</blockquote>
<br>
They are where I am currently getting the authoritative list of
timezones. However this list does not seem to be quite appropriate to
expose users to directly. Read my original post, I've explained it a
little more there.<br>
Thanks,<br>
- Naz.<br>
</body>
</html>
Naz Gassiep <naz@mira.net> writes:
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.
Feel free to filter things you don't think are popular. I'd be inclined
to delete Etc/ posix/ and right/ (the latter two only show up on some
platforms). Another idea is to not show anything more than an hour or
two off from where you think the user is.
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.
I think that's pretty unlikely to happen, unless you switch to a
different platform.
regards, tom lane