Feature Request: Access IP Address of Device (to Calculate Timezone)


#1

I’m working out a series of multi-jurisdictional timezone issues.

If we had access to the device IP address, I could quickly determine the time zone of the IP.

I think it would be highly beneficial to add this feature, along with a simple extraction of the “timezoneID” (formatted properly like “America/New York”) so that it could be used as an absolute value.

You can access the location of the user, but that takes permissions and GPS…

Allowing the current date object to output the TimeZone ID (America/New York) from the device is the way to go as it is 100% absolute and can be relied upon as it calls form the device itself regardless of internet connection, IP, or lat/long geo locale.


#2

Hi @justincrabbe… I answered similarly in a different time zone post you put on the forum but I’ll add more here…

The whole “America/New York” style is not the best practice when it comes to how software handles time management. There’s a numeric code that is used instead that tells you how far away from GMT you are. The UTC time code includes the +/- GMT code. This tells you precisely the distance from GMT the current time is.

To illustrate this… create a current date object, then create a string from date and format how you like… In my example, you can see I used the “Z” in the format which signifies that I want to know the UTC timezone code as well.

Then set a label to display that string for testing the result. You will see the time appear as well as the +/- code for how far from GMT (Greenwich Mean Time).

This is the info you want to use. Don’t rely on “America/New York”. Use the provided numbers to know what you need to do in the backend. In the backend, you can research the best means for date storing and management. I don’t have the best answer for you there but I do know that some use the UNIX milliseconds time code to keep everything on the same scale and only deal with time zone when it comes to delivering back the data to a device. This would be something to research on your end as I’m not super sure what’s best for you when it comes to date/time storage management for your specific use case in your backend.

As for tracking an IP, we don’t have that custom ability in Dropsource. The phone is responsible for knowing its current timezone so the phone displays the proper date/time on the phone screen. That same data it uses is where your “current date object” finds its data as well. You don’t need to use GPS. The phone is pinging cell towers and wifi access points constantly and that’s how the time magically updates on our phones. We’re just tapping into that genius so there’s no need to use GPS just to get a timezone if that’s all you need. It’s like how when you’re on an international flight, your phone will update it’s clock when connected to wifi but if not, it may or may not depending on the WIFI on the plane. BUT… when the plane lands, the phone is pinging cell towers again looking for a network it’s allowed to connect to (via your sim card) and even if it doesn’t find a network, it at least gain enough info from the connection attempt to update its time to the correct timezone.

See below the setup for HH:mm and Z. SO this is the time locally plus the timezone difference the web simulator is currently in. This would be different if I used my phone as I am currently in Bali Indonesia so I am in a different timezone and my date object would reflect that without GPS but from the information the phone as pulled in already.

I hope this helps illustrate how to use these codes in your design.



#3

The problem is GMT offsets change from country to country.

If you look at the map below, it’s quite sporadic in terms of the timezone (offsets) lines as you can see:

To complicate further, countries sometimes announce 5 days before they were supposed to be changing to daylight savings time that they aren’t doing it anymore…

A date can be saved with an offset of -7 hrs today, but what happens to that date when they change to daylight savings?

Or in 3 years when that country no longer participates in daylight savings?

If Airbnb didn’t collect the timezone ID of the property location, how would someone from a different timezone block off the date correctly in their calendar and determine the start of that day, and the end of that day, in the timezone of the Airbnb property?

It’s not absolute unless you have the actual timezone ID (America/New_York)

The best way seems to be by use of the timezone ID as it’s absolute and in 5 years if something about that zone has changed your date is still correct.

Our back end is able to take a date and display it according to a different timezone ID (America/New_York) than the original timezone which it was constructed in, but without the zone ID we’re out of luck in terms of manipulating the output of a date captured via dropsource.

Stack overflow and android developer forums have lots on the topic and say that if you can’t determine what timezone ID the date was originally constructed in, you are out of luck if you want to re-format that date into another date using a timezone ID if your choice.

See here about retrieving timezone ID’s in the correct format, not just by outputting the Z (offset) or the abbreviation of the zone like EDT (which, for some reason, abbreviations doesn’t always appear in the dropsource current date object when i switch my device to a Russian location for example observing the ‘Z’)

From https://stackoverflow.com/questions/7672597/how-to-get-timezone-from-android-mobile

" > Most applications will use TimeZone.getDefault() which returns a TimeZone based on the time zone where the program is running."

The output would be: > TimeZone GMT+09:30 Timezon id :: Australia/Darwin

It is the “Australia/Darwin” ID that’s important so that it can be saved and so that you can determine a parallel date in another location of the world.

Adding the TimeZone ID in “Australia/Darwin” format to the dropsource ‘current date’ object that already exists makes quite a lot of sense.

Right now we can’t figure out where the user is creating a date, and it’s leading to ambiguity in the results where we use the offset but the offset changes from country to country.


#4

Thanks @justincrabbe. I appeciate the in depth response and how this effects your important requirements. The importance of this in your use case and your need to adhere to even the most rapid change in a countries timezone setup requires you to get creative outside of Dropsource.

We don’t have the ability to provide info beyond what I explained above so let’s figure out how to get you some info from the device to handle this in your backend.

What I think you’ll have to do in this particular case is get approval from the user to gain the device location so you can send the Lat/Lon to your backend where you can then determine the time zone based on those coordinates since it’s not something we can handle in app.

If the user doesn’t agree to give location data, you might have to take the best info you can from the suggestion in my last reply. If that won’t work at all for your requirements however, then you’ll have to stop the user from continuing forward I guess. There’s not a whole lot more I can help with if the user doesn’t grant you location data when your needs are so strictly requiring that level of time zone information data.