I have some code checked in (but not released) that automates setting the time zone of observations based on time zone boundaries extracted from Open Street Map. My extremely limited experiments suggest that these boundaries are really good… and that existing observation time zones are a total mess. My changes would set the time zone based on the coordinates when
You add a new observation with coordinates
You change the coordinates of an existing observation
It removes any indication of time zone from the Uploader, and it will ignore the user’s time zone and any time zone information in the date string if coordinates are present.
It still allows you to edit an observation and manually change the time zone (even if there are coordinates), and it does not make any attempt to fix the many, many, many existing observations with wrong time zones (though we could).
If it changes a time zone based on the coordinates, it will only change the time zone, e.g. if your obs is at 2pm in Berlin and you change the coordinates to Quito, the obs time will be 2pm in Ecuador time, not whatever 2pm in Central European time would be in Ecuador time.
Can anyone think of any problems with this? It seems pretty un-intrusive, but the potential for problems is pretty sweeping so I figured I’d check and see if anyone envisions any disaster.
wouldn’t it be more elegant to identify to the user that there is a mismatch between time zone entered (or in the media metadata) vs the OSM time zone? then ask the user either to take the OSM time zone, or convert the time from the user time zone to the OSM time zone?
the times and timezones for my observations mostly come from my photo metadata. the clock on my devices is usually correct for my home timezone. when travelling, i’m unlikely to change the time on the devices without changing the timezone. however, i have been known to keep the time on my devices set at the time of my home timezone. so i think what you’re proposing would result in bad times if i’m making observations outside of my home timezone and haven’t updated my device’s clock.
i suppose there are people who change the time on their devices without ever considering the timezone. maybe that’s the problem you’re trying to solve?
Me too, accidentally, which is why I would be concerned about having it
Instead, I think it should pay attention to that information when it exists in the photo or device metadata (but ignore the account settings), and when there is a mismatch between incoming time zone and coordinate-based time zone, convert the incoming date-time to match the coordinate-based time zone.
Also, are you thinking of overlooking any geoprivacy or large inaccuracies when determining the coordinate-based time zone?
It seems to me that if someone takes a photo in a faraway place but for whatever reason didn’t change the camera’s time or their account settings, the time isn’t really wrong–it’s just stated in an unusual way. But I may be missing something here.
I suppose the only way to know for certain what problems might arise is to release the code and see what happens. I know I had problems at one time apparently because of a mismatch between the EXIF time at my location (GMT +11) and the time zone set in my iNaturalist account (GMT -8 default perhaps). The observations were deemed to be “in the future” and not a valid observation date. That problem was fixed by ensuring the time set in my iNaturalist account matched the time zone in which the observation was made. All I know is that if there are going to be issues that relate to time, this time zone and the one to the east will be the first two to arrive at the problematic time. For what it is worth, I am using iNaturalist beta on my Android.
Any assumptions made about times reported by photo metadata are likely going to be wrong. Individual camera users may or may not reset times to new timezones as they travel (although most phone cameras will do this automatically). On top of this problem, the EXIF standard for photo metadata did not include timezone information until very recently, so many cameras will not even report the timezone (none of my 3 cameras, including my phone, report timezone), and those that do may use non-standard fields to do so. So, I don’t see any way for iNat to “correct” reported timezones or times - the only way this can be done is to try to cajole users to correct times that seem to be wrong (daylight photos with a night-time timestamp?).
Because it is impossible to know how any particular user is reporting time and timezone (and frankly, many users won’t know how their camera time is set), I think Shin-ichi’s suggestion may be counter-productive - resetting the time zone when the actual clock setting is unknown is as likely to introduce errors as to correct them. At least if the user’s timezone doesn’t match the map timezone, there is reason to suspect the observation timestamp. If iNat automatically changes the timezone to match the locality, then any indication of potential errors is lost.
Yes, if there is no incoming time zone to compare with the incoming coordinates, then there is no basis for any adjustment to the incoming date-time. In which case, I think Ken-ichi’s idea is just to go ahead and add the coordinate-based time zone to the incoming date-time anyway. The “zone-less” date-time coming in will be just as right or just as wrong with or without the time zone added. But with it added, the observer would be more likely to notice and fix any error.
I really would like it, when I started an account I missed the option to change time zone, so big portion of my obs are still on Hawaii time and some on a different zone that I don’t remember, I change all I see, but there’re too many and it’s not my priority.
This is only the Uploader and is webbased by Chrome or IE ? With my iPhone camera and iphone iNaturalist app i did not had problems in many countries (THailand, Sri lanka, Cuba, Indonesie, Portugal etc)
Ok, apologies for not prefacing this with some description of the problem. Personally, I run into problems when I travel to different time zones and either forget to change my camera’s clock or forget to change my iNat time zone, or both. Usually I have to fix this by using the time offset tool in my photo editor or the extremely clunky batch edit functionality on iNat. Setting the time zone based on coordinates removes one of these sources of error. Yes, it introduces another type of error that @pisum described, but at least the behavior is more consistent and the error is easier to isolate, i.e. if the time looks weird, it’s b/c of the time you provided to iNat, not because of any time zone choice (or lack thereof).
More generally, as @fffffffff indicated (or demonstrated), most people are not aware you can change your time zone on iNat, and we do a terrible job of setting it automatically on sign up:
Top 10 Time Zones By Number of Users (Not Spammer, Not Suspended)
time_zone | count
-----------------------------+--------
| 198563
Eastern Time (US & Canada) | 21865
Pacific Time (US & Canada) | 15846
Hawaii | 14353
Central Time (US & Canada) | 12497
Mexico City | 3206
Mountain Time (US & Canada) | 3089
Auckland | 1872
American Samoa | 1458
Paris | 1447
Note that we do not have more Hawaiians than Mexicans. That’s just the top choice in the time zone selector. That’s just users, though. What about actual observations? For the 100,000 most recent verifiable observations, 28,632 ( 28.6%) of them had a time zone offset that didn’t match their coordinates. That means while the time might be right or wrong, the absolute datetime is probably wrong for 29% of those observations. This is a slow calculation to perform, so I can’t get numbers on a more representative sample at the moment, but I really doubt it would be much better.
Also, for what it’s worth
We don’t currently do anything with the offset included in EXIF timestamps. As stated above, this is rarely present. Also, the offset is not the time zone (Pacific Time and Arizona Time are two time zones that have the same offset half of the year), so even if we did use it we would be wrong some of the time. In the Uploader we just the use time zone associated with the user’s account. In the mobile apps, we encode a representation of the datetime observed that includes the time zone when the obs was recorded. If you import a photo, I suspect we use the zone in use at the time of import, which undoubtedly leads to some problems that would also be solved by my proposal.
The time zone reported in the text representations we use in the mobile apps and in Javascript is imperfect. We engage in all sorts of hideous contortions to extract a usable time zone from that text, but since there are a number of different time zones that have the same abbreviations, we can’t do it for the following: AST, BRT, BST, CDT, CST, ECT, GST, IST, PST
Why do we even have time zones in iNat? This was probably a mistake, originally, but at this point I think we need them for bioblitzes and such that span multiple time zones.
I would certainly use the hidden coordinate to determine the time zone in those cases, which yes, could provide more grist for people trying to guess them, but the cost of not using them seems higher. I would not consider large inaccuracies. Using the point alone seems good enough almost all of the time.
I’m not sure I understand this. If I fly from California to New York, forget to update my camera’s clock, take a photo at 5pm EST so the camera registers it as taken at 2pm (PST), and post it to iNat, it will show up as 2pm EST: camera time plus location time zone. I will look at that and think, wait a minute, I didn’t take that at 2pm. Oh crap, I forgot to update my camera. The indication of error is that the time is wrong.
Who’s this Shin-ichi guy?
Indeed, b/c most of the time that three-letter time zone code we can make in the apps at the time of observation suffices. Just not all of the time.
The critique that’s holding the most weight for me so far is the didn’t-change-my-camera-settings AND didn’t-change-my-iNat-time-zone travel argument, mostly b/c you can address that now by batch-editing the time zone. What if we added a time-offset tool to the Uploader? That way you could shift observations forward or backward a few hours before you upload them.
ok. with the problem clarified, i think the proper workflow would be:
user adds observations (including specifying time manually, if needed).
as locations and datetimes are added, the system pulls the timezones based on location from the OSM boundaries, and compares to the timezones defaulted or specified in the observations by the user. for now, the system will simply flag the observations. if a user clicks on a flag, the system will offer an explanation and a way to fix the datetimes (see #4 below).
as a quality check when observations are submitted, the system reports that there are flagged mismatches (#2 above) and offers an explanation and a way to fix the datetimes (see #4 below).
the system will list all mismatches with a checkbox to select/deselect each record (and master checkbox to select/deselect all), and offer 5 possible options:
a. accept the user-input datetimes, but apply the OSM timezone in the observations, and keep user’s default timezone unchanged.
b. accept the user-input datetimes, but apply the OSM timezone in the observations, and change the user’s default timezone to the OSM timezone. (this option not available if there are multiple OSM timezones in the observation set.
c. offer to convert datetimes to another timezone. along with 2 droplists to select source timezone and target timezone. the source timezone should default to the user default timezone, and the target timezone. the target timezone should be applied to the resulting converted datetimes.
d. let the user correct records manually
e. do nothing, and submit the records as they are.
** if a user applies a, b, or c, and there are still mismatches afterward, the system should offer an updated list of mismatches and the same 4 options.
of course, if no timezone can be extracted from time and location (because missing location, missing time, etc.), then such records will be excluded from the workflow above (drop out at #2), or else add handling for bad times/locations in the workflow above.
What happens currently if I upload pictures taken on a device where I didn’t change the time? I imported 3 old photos from Flickr last night taken in Florida. They are from 2012 and I can’t remember if I changed my camera time but I doubt it. The times on the observations are showing up for me in GMT (UK time) and look like they would translate to plausible times in Florida.
Photos almost never come to us with time zone information, so we just take the time and assume it’s in the time zone you’ve chosen in your user preferences.
I’m a logical, computer-programming thinker and read the complications people were assuming. I understood the concept from the original message, understood what people were suggesting and remain in favour of this. As stated, time-zones are “almost never” received so applying the most logical time-zone (based on location) is the right thing to do. The only problems I see is when people are near the border.
Cool, my times should be correct then. I think some kind of indication that the time zone might be incorrect when creating the observation could be useful.
Sounds right to me. Is the time stated in the same way for everyone? So would someone on the EST timezone see this observation as 8:27 PM GMT rather 3:27 PM EST?
