| From: | "A(dot)M(dot)" <agentm(at)themactionfaction(dot)com> | 
|---|---|
| To: | Postgres General <pgsql-general(at)postgresql(dot)org> | 
| Subject: | Re: User-Friendly TimeZone List | 
| Date: | 2007-08-15 19:36:41 | 
| Message-ID: | 61BBE3A5-65FA-4EE6-BC81-3502317B97DF@themactionfaction.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-general | 
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | btober | 2007-08-15 19:39:39 | Re: SELECT ... FOR UPDATE performance costs? alternatives? | 
| Previous Message | Erik Jones | 2007-08-15 19:18:17 | Re: SELECT ... FOR UPDATE performance costs? alternatives? |