Just a question. What's the relative priority of this? Why is it
important that Cosmo handle the timezone list differently from the
desktop. Maybe there is and I am just not in the loop.
On Apr 30, 2007, at 11:03 AM, Priscilla Chung wrote:
I like the second proposal you made. Please see my reply inline:
On Apr 24, 2007, at 10:48 AM, Bobby Rullo wrote:
*First Proposal*
The convention of eastern, central, mountain and pacific time
zones are more conventionally understood then time zones by city
names.
True.
Is it possible to include the time zone abbreviations (EST, PST,
etc.) in the drop down list? This is in addition to the region/
city names? Specific the regions in the United States, it may be
listed starting from eastern to pacific time for example:
EST Boston
EST New York
EST Washington DC
CST Chicago
CST Dallas
MST Denver
MST Tuscon
PST Los Angeles
PST San Francisco
PST Seattle
It is possible.
Would this replace the US timezones that are there now?
Yes.
Or just precede them in the list (or follow them?) Would there
still be 2 drop downs, one for region, one for timezone?
No there would just be one drop down.
Do we really want multiple PST's, MST's, ETS's?
Yes.
That might confuse people into thinking that they're different.
That's true—maybe not the best thing to do.
And since they are alises to the same thing, you would choose "EST
Boston" but what would really get saved is "America/New_York".
Would it be a requirement that Cosmo UI "remember" which specific
alias you chose?
Yes it would be. I'm guess this is more work to do.
I know that there is both standard and daylight, is it possible
to change the list depending on time of year? The more relevant
question is if the web app will support daylight savings time?
That's not how it works exactly. "America/New_York" for example is
one timezone, and contains the necessary to change the the offset
from daylight to standard at the appropriate time.
Understood. I was talking about the display of the time zone
because it's convention to show pacific time for example as PDT
when it's pacific daylight time and then show PST when it's pacific
standard time, ie. the display changes depending on the time of year.
*Second Proposal*
Similar to the desktop, provide one drop down list for the user
to choose from. In this drop down list, the region, cities and
abbreviations are combined.
For example:
| Pacific/ Honolulu | V |
| America/Anchorage |
| America/Los Angeles |
| America/New York |
| Floating |
| More… |
The idea is good, but the example you give has cities but not
abbreviations or names. Maybe something like:
Eastern (New York, Boston)
Central (Detroit, Louisville)
Mountain (Boulder, Billings)
Pacific (San Francisco, Los Angeles)
I like this idea and prefer listing out the time zone names over
the acronym names.
or
EST (...)
CST (...)
MST (...)
PST (...)
Of course this is all very US-centric. What to be done for our
users in other countries?
Other countries would follow the following convention:
+ if there is only one time zone in the country, list out city
name, country name; ie. Paris, France
+ if there are multiple time zones similar to the US model, list
out country name, time zone, (city list); ie. US Eastern (New York,
Washington) or CAN Eastern (Toronto, Montréal)
Just put them in the settings dialog, with the same interface we
have today?
The default short list should consist of US, Canadian, and European
time zone. Or basically we wan to support the countries we expect
to try and use the hub.
In the longer term, the ability to determine where someone was
logging in from and present in a short list of the most relevant
set of time zones would be ideal.
Hope this makes sense. -Priscilla
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
