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’)
" > 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.