More cities and GMT-style options in time zone selection

[deepad]

Title:
More cities and GMT-style options in time zone selection

Area:
posting

Summary:
The drop-down options right now to set your time zone offer an extremely limited number of Continent/City options to choose from. This should be increased and diversified to accomodate users from all parts of the world.

Description:
So in changing my time zone to get GMT + 5:30, I discovered that the only option I had was to select "Asia/Kolkata". No mention of Mumbai or Delhi or Bangalore or any of the other big cities, and worse, no GMT option.

This requires people not living in the US to have to look up which of the small and randomly chosen list of cities their location matches in the time zone department.

So I would suggest that the system either be changed to Greenwich Mean Time (GMT), or else if the present Continent/City one remains an option, make it Continent/Country for all nations that have one time zone. Or if Continent/City must be kept, add to the number of cities represented.

Poll #4509 More cities and GMT-style options in time zone selection

Open to: Registered Users, detailed results viewable to: All, participants: 64

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
52 (81.2%)

Should be implemented with changes. (please comment)
8 (12.5%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
4 (6.2%)

(Other: please comment)
0 (0.0%)

Comments

[ninetydegrees]

+1 to adding GMT/UTC + number.

if the present Continent/City one remains an option, make it Continent/Country for all nations that have one time zone

+1 to this. Actually +1 million.

[thomasneo]

+1 to adding GMT/UTC + number.

This.

[ursamajor]

I'm more of a fan of Continent/Country than expanding the number of cities, just because I think the list of city-names expanding could get unwieldy really fast. What determines what cities should be included? Absolute population? Relative population compared to the rest of a given timezone?

OTOH, I still think the current list is incredibly unwieldy already, so I'd love to see it split into multiple interdependent dropdown menus.* I picture two dropdowns: first you pick your continent, then your country. A third box could then appear to pick your timezone if your country has multiple timezones (and for the sake of inclusion, I'd prefer box #3 to be timezones rather than cities).

(*dw_accessibility peeps, are there accessibility issues with this? I feel like the existing choice isn't a good user experience, but I don't know enough about how browsers work outside IE/FF/Chrome/Opera/Safari-world. How well they support JavaScript, for example, which to my knowledge is key in getting the multi-menu thing to work properly.)

One other complicating factor is Daylight Saving Time - sometimes, an entire country practices it (or doesn't practice it), and has maintained that practice for years; other times, countries are still experimenting with it, or have areas that *legally* do something different than the rest of the country. Arizona, for example, lies in the Mountain time zone, but does not follow DST. However, the Navajo Nation that lies within Arizona *does* follow DST - but the Hopi Nation, which lies within the Navajo Nation, does not. Dropdown 1: "North America;" Dropdown 2: "United States." Dropdown 3: what goes here? Arizona as a whole stays at UTC -7 all year round; many DST-observing parts of the Pacific timezone migrate here for the summer, swapping out the DST-observing parts of the Mountain timezone ...

Per Wikipedia, there are also plenty of unofficial time observance practices as well. I think it's going to be a balance of trying to keep things user-friendly (as a technical interface) vs. being fully inclusive of all persons and timezone practices, but I also suspect this will go to a programmer more advanced than me. ;)

[aedifica]

+1 I agree that having the list be more inclusive as deepad suggests would be a good thing, however in my job I regularly have to sort through lists of time zones to try to find mine (yes, seriously--setting up new computers for end users) and the lists *are* really unwieldy. ursamajor's suggestion would help with that.

[matgb]

Arizona, for example, lies in the Mountain time zone, but does not follow DST. However, the Navajo Nation that lies within Arizona *does* follow DST - but the Hopi Nation, which lies within the Navajo Nation, does not

Really? There's so much fuss within the UK about whther we should fix to double summer time, and the effect it'd have on Scotland, it's always confused me why we can't have different choices, sot hat's useful.

PErsonally, I don't see the point of including the country at all, just have a timzone picker. Having to list both Europe/UK and Europe/Portugal plus Africa/Sierra Leone seems daft to me, just list GMT.

[kyrielle]

Except if you do it by GMT without accounting for daylight savings time, then some of us have to change it twice a year. Adding a tickbox for daylight savings time would help, but are there different dates to start/end it in different countries?

And some people don't know GMT offsets in their head at all - in fact, I'd say the majority of people I know here in the US don't. If they don't deal in computers or technical stuff, and don't know anyone in that time zone, the odds are they don't know the GMT offset.

[matgb]

I'd say the majority of people I know here in the US don't

Hmm, what about using time zone names? I, who's only been to the US a few times, know about Pacific Standard and Mountain Time, and for many that'd be clearer than a list of cities that may or may not be useful.

[jd]

For the record, Hawaiʻi doesn't observe DST either, but they're actually tropical, so it's more justified.

[turlough]

+1

[jadelennox]

from an accessibility standpoint, there's any number of issues, and they don't point to one clear answer.

I'm a big fan of just putting in the GMT +/- numbers, but that can be difficult for keyboard or screen reader navigation of a drop-down list. Sure, you can arrow key down, but is everything in the list begins with "GMT", then you can't just take the first letter of the thing you want and skip directly there.

Multiple drop-down lists are great, but you need to have a non-JavaScript option both for accessibility and for people who don't use JavaScript. Maybe if you don't use JavaScript, then you just pre-populate the entire list with everything? And you need to make sure that the JavaScript does use ARIA to deal with the updating live regions of the newly populating secondary lists.

[azurelunatic]

And then there are the different dates that places swap back and forth on -- I was trying to make a spreadsheet-based timekeeping system for my chatfish, and it got really out of hand really fast.

Do we know of any reliable external services that keep close track of various times across the world, where we can just import something from them and keep it updated?

For UI, what I would do is:

Pick current local time. From the current local time, the system then looks up all of the possible timezones in the world that currently have that time, and displays them to pick from. For shiny, it might display a map with major cities for each zone (text-only would name the region and list that includes these major cities). The plain GMT offset (don't pick a region, leave my time at GMT +/- whatever until I change it) would also be an option.

[exor674]

I sorta like your idea:

Additional idea, for even more shiny if the user supports JavaScript, either -- I'm not sure what is better:

* Interrogate all the timezones that currently match the users time for the DST rules ( or failing that, get the times for midnight on the first day of the next 12 months -- hoping that hits a DST transition ), and when presenting users the options, pass that info ( UTC time and matching local time ) along and some JS magic in the browser would create dates from those UTC times and make sure they match what they should be -- disqualifying any that don't.

* Grab the local and UTC time for the first day at midnight local time of the next 12 months ( does DST ever last less then a month anywhere? *g* ), and send that along and let the server disqualify things.

[msilverstar]

http://timeanddate.com/ is very reliable, but I don't know how they feel about API calls.

I know most people have no clue about their GMT offset, especially as it changes back and forth during DST. So there have to be countries and timezone subunits, but not every city in the world. Sometimes it's silly, PST represented by Vancouver BC and Acapulco, Mexico, but missing the larger cities of LA, SF Bay Area, and Seattle.

Dropdown lists are not the only way, either. Maybe get their ip address and match that to the time, but assume it may be wrong, so set the defaults and let them override.

[quillori]

I'm fairly sure the current set up is the standard list from the tz database, which presumably is what DW are using to keep track of DST around the world. There's an explanation of how the names work here.

I must admit I'm leaning towards leaving the list the way it is - it's a widely used standard, and where would you stop adding other cities? The list's pretty long as it is. I wouldn't mind having a second option to set the GMT/UTC offset instead, though, for those who prefer it, in which case, for simplicity, no automatic adjustment would be made for daylight saving.

[thorfinn]

The posix zoneinfo system keeps track of this information, including historical data about when various zones fall in and out of DST as well as current.

[quillori]

I'd be in favour of having at least a GMT style option, and probably just GMT style - on the one hand, it's more trouble for users who don't already know their time relative to GMT, but on the other, it's accurate without the need for lengthy lists of every possible city, and without someone at DW having to figure out every possible timezone in each region, which can, as ursamajor pointed out, be tricky. (As a minor aside, from my personal POV, I'm not always working on the time zone of the place I physically am, and it seems somehow weird to set things to a place I'm not, whereas it wouldn't be at all weird to set it to GMT + an appropriate number.)

[matgb]

probably just GMT style ... more trouble for users who don't already know their time relative to GMT

Maybe just have timezones within the drop down, but have a handy help link to help people look it up if they're confused?

[quillori]

I think that would be a good compromise, and probably actually easier on the user than either having an endless list of places to read through to find yours, or having to figure out which of the listed cities is in your time zone. The only problem I can see is with daylight saving. Actually, thinking about it, is the current set up done off the tz database? That would explain why those particular places. Hmm... I'd still prefer GMT offset, in part because I travel so much it's easier than constantly trying to figure out where I am on the tz database list, but it would be a pain to set up a GMT style option to do automatic daylight saving adjustments - you'd need a first list of the (I think) 42 offsets in current use, and then, if you picked one of the options that includes places with daylight saving, a second list to identify whether that applies to you or not, which would probably have to be a version of the relevant bit of the tz database anyway. Perhaps a better plan would be to have two options? Either pick your place off the tz database list (perhaps, if there's a problem with people wondering why their nearest city wasn't included, with a link to an article about it, so people know how the particular places came to be picked?), or input your GMT offset, but in the latter case any adjustment for daylight saving will have to be done manually. [ETA I mean, manually by the individual user, when they're changing all their other clocks, not that someone at DW should be expected to try to figure it out.] Personally, I'd really, really prefer the GMT option, but I can see, thinking about it, why it might not be the best for other people.

[thorfinn]

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.

[kyrielle]

I don't feel strongly about this but agree that either of these solutions could work. I think the second one (a list entry of "Specify GMT offset" and an edit box in which to do so) is probably less clutter for the users who don't want it / don't understand it, but either could work.

I don't want to see a ginormous list of every possible city/country ever; I don't want to see a separately-maintained list; I don't want to have to do my own GMT and time zone calculations when there's a perfectly good list; but I can see where the ability to specify a GMT offset could be useful.

And if there's a site or sites on the web that let you search by an address or a city name or whatever and spit out the time zone you want (preferably the zoneinfo one if that's what we're using), a helpful link to that might be, well, helpful.

[denise]

So generally when I decide on a suggestion's ultimate fate, I don't comment (figuring the discussion is usually good enough for people to work out my reasoning) but in this case, I wanted to!

I'm going to be setting this suggestion's status to "deferred", which means "I'll come back to it later to see if things have changed". The reason I'm not migrating it into Bugzilla is that -- as noted in some of the earlier comments -- the list we use isn't manually compiled; we use one of the standard Unix utilities for calculating timezones, etc. Because of that, any changes to the timezone list would require us to essentially create an entirely new timezone management system from scratch (even if it's just to add more cities, as this suggestion proposes), with all the headaches of managing and updating that system as times and timezones change around the world.

So, this suggestion is not rejected, precisely, but since timezone management is so not our core strength, and maintaining a system like this would take a lot of resources that we don't necessarily have to spare, I'm calling it deferred until/unless we can find a package out there with better city->timezone data. If we can find a GPL-compatible package that has better timezone management, and better city/country/timezone data, I would love to integrate it. I will keep my eyes open for one.