Make WordPress Core

Opened 15 years ago

Last modified 5 years ago

#10660 assigned feature request

Time zone suggester based on nascent API call

Reported by: sambauers's profile sambauers Owned by: rmccue's profile rmccue
Milestone: Future Release Priority: normal
Severity: normal Version: 2.8.4
Component: Date/Time Keywords: needs-patch dev-feedback
Focuses: javascript Cc:


The attached patch uses a new API call to to retrieve a suggested time zone based on client (not server) IP address.

A button is added next to the existing dropdown list of time zones providing the option to "Suggest a time zone". This calls the API using an AJAX/JSONP request which then auto-selects a time zone for the user from the dropdown.

Visual feedback is via a spinner when fetching and then a text response.

Additionally the Date and Time settings have been split out to a new settings page.

Related ticket: #10324

Attachments (3)

datetime-and-timezone-suggest.patch (22.2 KB) - added by sambauers 15 years ago.
10660.diff (4.1 KB) - added by rmccue 14 years ago.
Updated (and simpler) patch
10660-refresh.diff (3.5 KB) - added by rmccue 12 years ago.
Refresh patch

Download all attachments as: .zip

Change History (29)

#1 @sambauers
15 years ago

An attribution for use of GeoNames will need to be included somewhere in the interface or on the site/docs for us to be able to use this.

#2 @Otto42
15 years ago

  • Cc otto@… added

#3 @cnorris23
15 years ago

  • Cc cnorris23@… added

#4 @nacin
14 years ago

  • Milestone changed from Unassigned to 3.1
  • Type changed from task (blessed) to feature request

Moving to 3.1. Not sure we need to spawn another options panel for this though.

#5 @nacin
14 years ago

  • Milestone changed from Awaiting Triage to Future Release

14 years ago

Updated (and simpler) patch

#6 @rmccue
14 years ago

  • Keywords gci added
  • Owner set to rmccue
  • Status changed from new to assigned

This updated patch does the same as Sam's, but simpler, and also asks the user before using the supplied timezone as the value.

#7 @danielbachhuber
13 years ago

  • Cc d@… added

#8 follow-up: @azaozz
13 years ago

I see this as "pure" JS based solution. The browser "knows" the right timezone and the UTC offset. The user's IP might not be in the same timezone (proxy?).

#9 @Otto42
12 years ago

We have a name-to-zoneinfo API call too:

Could be good for auto-suggest based on search string.

12 years ago

Refresh patch

#10 @Otto42
12 years ago

#10324 was marked as a duplicate.

#11 @helenyhou
12 years ago

#9759 was marked as a duplicate.

#12 @helenyhou
12 years ago

  • Component changed from Administration to Date/Time

#13 @travisnorthcutt
11 years ago

  • Cc travis@… added might be a candidate for use... grabs a timezone as opposed to a UTC offset, and is MIT licensed so inclusion in core should be possible.

#15 @travisnorthcutt
11 years ago

Not my area of expertise, but if it works, then great.

I'm not one to look a gift horse in the mouth ;)

#16 @ericlewis
11 years ago

There is a jQuery Timezone picker that could be considered to solve this problem as well. Finding your place on a world map is an instantly understood UI, and adds a bit of character.

#18 in reply to: ↑ 17 ; follow-up: @rmccue
10 years ago

Replying to ericlewis:

Another option: timezone selection with d3

Cool, but not accurate (it's missing the Sydney timezone, at least). The jQuery library is a better interface IMO, and looks more accurate.

#19 in reply to: ↑ 18 @ericlewis
10 years ago

Replying to rmccue

Cool, but not accurate (it's missing the Sydney timezone, at least). The jQuery library is a better interface IMO, and looks more accurate.

The d3 example is crude, but there would be benefits with D3. There's Low overhead for complete control over the map.

Since D3 uses SVG, we could use the new admin color schemes to inform the map's colors.

Finding the right timezone tiling shouldn't be too hard either since it uses GeoJSON.

Last edited 10 years ago by ericlewis (previous) (diff)

#20 @sambauers
10 years ago

The jQuery one is much nicer, and the payload overhead is about the same as the D3 one. The D3 JS is about @40KB Gzipped. The extra JS on the jQuery one is @4KB + the map image is about @35KB.

Supporting a jQuery plugin is less development overhead than adding a new library.

Best zombie ticket ever BTW!

#21 @chriscct7
9 years ago

  • Keywords needs-patch dev-feedback added; has-patch gci removed

#22 in reply to: ↑ 8 @ericlewis
9 years ago

Replying to azaozz:

I see this as "pure" JS based solution. The browser "knows" the right timezone and the UTC offset. The user's IP might not be in the same timezone (proxy?).

Coming back, this seems the best solution, please excuse my earnest vision of using D3 here.

#23 @rmccue
8 years ago

I implemented timezone detection via the browser for a project I was working on. Unfortunately, the browser doesn't report the Olsen timezone via JS, only the timezone offset. There's a nice little library that applies heuristics based on the offset and DST information, but this isn't native to the browser.

One potentially easier solution would be to use getTimezoneOffset() to provide filtered suggestions for the picker, and expose these to the user. This would require outputting the timezone offset in wp_timezone_choice(), which would also allow us to show the current time live as you change the timezone.

#24 @Otto42
8 years ago

Sad to say that an 11+ K script (after minification) is currently the best option for browser side detection. Still seems to have quite a few issues though, several in their list involve it giving different answers on different browsers.

It's worth noting that the current WP code basically outputs all the timezones PHP knows about, including historical ones. It might be worth trimming that down to only modern timezones, in the same way that the library above does. Looks like they're only including 72 current timezones, approximately.

#25 @dd32
8 years ago

  • Focuses javascript added

FWIW see this comment on #28988 by myself:

It looks like we'll be able to use Intl.DateTimeFormat().resolvedOptions().timeZone here now.

It's supported by recent Chrome & Safari, Firefox 52 will support it (Currently in the Developer channel), however IE is likely not implementing it. Progressive enhancement to support it when possible seems like a good option to me.

#26 @Rarst
5 years ago

Refreshing what's our options are at this time.

Is the suggested endpoint dead? ({"errorcode":5,"errormessage":"GeoNames API could not be contacted"})

Looked at Intl.DateTimeFormat().resolvedOptions().timeZone and browser support looks good by now (except IE), but there are reports that returned value is incorrect/inconsistent between browsers. Also the value might not at all be consistent with PHP time zone, which we need. I suppose we could do a very low hanging fruit implementation when suggestion is made if JS time zone matches exactly one of PHP time zones. Anything more comprehensive would require us to maintain complex multi-browser mapping from possible JS values to PHP ones.

Last edited 5 years ago by Rarst (previous) (diff)
Note: See TracTickets for help on using tickets.