1

I am working on a project in which time precision for multiple users with different timezones is extremely important.

I know the most accurate representation of the timezone to store would be its identifier (eg "Europe/Budapest")

but using "DateTimeZone::listAbbreviations()" AND "DateTimeZone::listIdentifiers()", I got 408 timezones (cities), which is not very user friendly to be used in a select box.

In order to make it more user friendly, I would need to put them in groups of timezones where they share the same offset and daylight saving.

I can't group them based on "Offset" because they change with daylight saving, or "Timezone abbreviation" (eg AST) which could contain elements of multiple offsets.

I see websites which are also very time sensitive, but they offer timezone selection in groups which are very user friendly and I wonder how do they group them or do they sacrifice accuracy for user friendliness?.

is there a way to do this that I am not aware of?

shar
  • 95
  • 1
  • 6

1 Answers1

1

Well, "best" is highly subjective, but I've seen this done in dropdown lists so many different ways, and they all tend to be confusing.

My recommendation would be to consider using a map-based time zone picker instead. The user won't need to know anything about time zones, they just click their location on a map.

There are several of these available, but my favorite for the web would be this control, which is primarily JavaScript. It should fit reasonably well into a PHP based solution.

Matt Johnson-Pint
  • 230,703
  • 74
  • 448
  • 575
  • it does sound like a good idea, but there are several problems with it, other than its compatibility issues with smartphone platforms, I think it might be more frustrating for users to visually try to find their country/city. also I think relying on PHP to populate the cities and zones, has a better chance of being updated automatically when there is change in dst or dst rules. – shar Jun 27 '13 at 03:42
  • It does work on smartphones, but it's a bit small - yes. Tablets are ok though. PHP uses the same [IANA/Olson](http://www.iana.org/time-zones) time zones as this script's source data. And while that changes multiple times a year, the [zone boundaries themselves](http://efele.net/maps/tz/world/) don't change any where near as often. (Usually the changes are to the rules a particular time zone follows, rather than where the time zone applies.) – Matt Johnson-Pint Jun 27 '13 at 03:49
  • BTW - I had the exact same [concern awhile back](http://stackoverflow.com/q/13056759/634824), but in .Net (with Noda Time) instead of PHP. I originally filtered the dropdown by country code and then sorted by *current* offset. Ultimately I changed this in favor of the map-picker. My users won't be picking their timezone from their phone though, so perhaps the dropdowns are better if that is a primary concern. – Matt Johnson-Pint Jun 27 '13 at 03:52
  • If you really want to see what others think is best, perhaps open this question from a design perspective on [ux.stackexchange.com](http://ux.stackexchange.com/). Maybe there's something we are both not thinking about. – Matt Johnson-Pint Jun 27 '13 at 04:16
  • I couldn't think how I can ask from design perspective, but I have been looking into it, I tried grouping the timezones together if their offset and dst times are exactly the same between 2013 and 2037 using "getTransitions", then I got a shorter list, but I know this will change, already PHP v5.3.10 returns 74 results and 5.4.15 return 77 with some items moved around. if I tried to divide the groups further by timezone abbreviation (eg AST, CST, etc), the number goes up to 171, which is better than 408. but still I know this won't do with later changes in timezones that will effect the list. – shar Jun 28 '13 at 07:03
  • then I tried looking around most commonly used timezones around internet, I found acceptable lists which I revised based on latest timezone changes and "getTransitions" that I mentioned in the previous post, to make sure that they will stay on the same timezone & dst for at least next 24 years (of course based on current rulings that exist in PHP, which will change in the future, but using this list the changes should have minimal effect on the list). here is the final result, it's the next best thing to perfect: [link]http://codepad.org/8uamN7lr – shar Jun 28 '13 at 07:12
  • Time zones have no guarantees about futures. Politicians rarely give that much notice. Especially in developing countries. Some of that data looks like it was based on CLDR metazones or Windows zone mappings - [see here](http://unicode.org/cldr/charts/supplemental/zone_tzid.html). You might just want to do what Google does (on Google Calendar settings, for example) by offering two dropdowns. One for country, and one for zones in that country. The country codes are mapped in `zone.tab` from the TZDB. You can see it [here](https://www.ietf.org/timezones/data/zone.tab). – Matt Johnson-Pint Jun 28 '13 at 07:25
  • Do understand though that PHP is not authorative for time zone data. They source it from [IANA](http://www.iana.org/time-zones). – Matt Johnson-Pint Jun 28 '13 at 07:33