Feature request: Automatically detect user timeZone based on GMT offset

Question

Feature request: Automatically detect user timeZone based on GMT offset

emrysal opened this issue 3 years ago · 16 comments

We've got a usecase where we want the use the dayjs.tz.guess() function, which for Italy for example may return Europe/Rome. This wouldn't resolve to anything in this case.

Perhaps it is an idea to do some kind of map of GMT offset to timeZone?

Answer 1 · 2021-04-27T11:57:10.000Z

Hey thanks for bringing this up!

So if I understand you correctly, you want to be able to pass in a GMT offset (i.e. GMT+2:00) and get back the full timezone object? spacetime supports something similar, does that fulfill your usecase? If not, maybe moment-timezone does?

Answer 2 · 2021-04-27T12:49:09.000Z

So the usecase is that we want to default select option to the applicable timeZone according to the user browser settings; this would work if the timeZone selection included all the timeZones that exist, but that list is very user unfriendly ux wise (hense we use this select). But we'd still like to be able to default the applicable select option based on user browser configuration.

So like: Europe/Rome => Europe/Brussels (or whichever timezone Rome actually is in)

Answer 3 · 2021-04-27T19:15:14.000Z

Ah okay, so we can probably relatively easily select the default timezone via the users browser language / country headers or something like that.

Would that fulfill your use case?

Answer 4 · 2021-04-27T19:15:49.000Z

How's this?

const [timezone, setTimezone] = useState<ITimezone>(Intl.DateTimeFormat().resolvedOptions().timeZone);
return <TimezoneSelect value={timezone} onChange={setTimezone}/>

I don't think this works in IE11 though.
https://caniuse.com/?search=DateTimeFormat

Answer 5 · 2021-04-27T20:16:19.000Z

Yeah just putting it as the default value in the useState call is what I would have done too. I didn't know the new Intl object had this though, thats awesome!

Regarding IE11, thats okay I dont plan on going out of my way to support that anyway..

Answer 6 · 2021-04-28T09:48:57.000Z

Hey so I've released a new version last night with a bunch of clean up.

Wasn't sure whether to put this into a prop the user could enable (i.e. showUserTimezoneByDefault) or something like that.

But just decided to throw it in the readme for now since it makes more sense for the user to use your little Intl snippet in "userland" when they're initialising the state.

Thanks again for the tip!

Answer 7 · 2021-04-28T14:12:23.000Z

@ndom91 You are very welcome. Thanks for making a wonderful open source component 😄

Answer 8 · 2021-04-28T14:18:25.000Z

Going to close this for now, if anyone comes across this looking for similar behavior - checkout @ndrwksr 's workaround in the comment above (#25 (comment)), or in the README.

Answer 9 · 2021-04-28T14:41:16.000Z

@ndom91 What I meant was what happens in the case the timezone is missing from the select. Attached a screenshot of what happens when the timeZone detected is Europe/Rome.

Added after initial comment: So Intl.DateTimeFormat().resolvedOptions().timeZone is a good way to do it, but then the missing piece of the puzzle is somehow - and I'm not quite sure what the appropriate solution is here - map back to one of the options within react-timezone-select.

Answer 10 · 2021-04-28T14:47:22.000Z

Ah gotcha.

Yeah so there's two ways to deal with this.

Either I expand the interior map to include every timezone in that "Europe/Rome" format.

Or I make this "setUserTimezoneByDefault" thing an internal prop, and then I can match user timezones that don't exist (like Europe/Rome) by offset to the matching existing choice (Europe/Berlin or Europe/Amsterdam I think it'd be).

What do you think?

I'm up for doing the second variant, that shouldn't be too hard. And doesn't change the user facing api other than adding a new boolean prop.

Answer 11 · 2021-04-28T15:08:04.000Z

The Dumb approach I came up with is to indeed get a list together of all timezones in existance, and map them to the relevant "Short list". I think it is desireable from this component POV to deal with valid timezones that are not part of the component display (in case people want to do this). I was wondering if there were smarter ways like detecting an entered timezone GMT offset, and then find the item in the list with the same GMT offset rules.

By logic, I think this belongs within the parseTimezone function (sidenote, this is typehinted ITimeZone but I think it's mixed at that point, either ITimezone or string, but alas). The way it can be handled is that when you pass "Europe/Rome" it returns an ITimeZone interface with Europe/Amsterdam, as that is the relevant match.

Answer 12 · 2021-04-28T19:37:04.000Z

@emrysal I believe this would be helpful:
https://github.com/spencermountain/timezone-soft/

Answer 13 · 2021-05-02T11:11:26.000Z

Btw @emrysal - regarding the union type ITimezone, this was done this way to support allowing people to just pass in "Europe/Amsterdam", for example, instead of the whole object. Mostly for backwards compatibility reasons. Maybe we should do a major version bump and just remove that..

Answer 14 · 2021-05-02T14:10:25.000Z

Hey everyone, @emrysal's PR to match any possible timezone to one in our list, has been merged! 🎉

This means you can safely use the Intl.DateTimeFormat().resolvedOptions().timeZone trick during state initialisation, and get a valid timezone selection out of this component 👍

Answer 15 · 2022-07-04T19:40:50.000Z

There is a problem with using Intl.DateTimeFormat().resolvedOptions().timeZone as a way to set the user timezone. say for example your timezone is Paris, Intl sets it as Europe/Paris and NOT Europe/Brussels which your library supports. now the selection works as you mentiend. Here is the Problem: I use your import {allTimezones} from "react-timezone-select"; to display the timezone label allTimezones[props.timeZone] this evaluates to undefined. because you don't support all timezone so Europe/Paris is undefined. I'm considering using GMT as default Selection and always forcing the user to select the timezone himself, because I really like your allTimezones object.

Answer 16 · 2022-07-05T04:27:58.000Z

There is a problem with using Intl.DateTimeFormat().resolvedOptions().timeZone as a way to set the user timezone. say for example your timezone is Paris, Intl sets it as Europe/Paris and NOT Europe/Brussels which your library supports. now the selection works as you mentiend. Here is the Problem: I use your import {allTimezones} from "react-timezone-select"; to display the timezone label allTimezones[props.timeZone] this evaluates to undefined. because you don't support all timezone so Europe/Paris is undefined. I'm considering using GMT as default Selection and always forcing the user to select the timezone himself, because I really like your allTimezones object.

Yeah this is a known issue, someone has suggested auto detecting the city and generating the timezones dynamically in this issue, but no movement yet.