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 @melodi_96 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.
- 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.
Sorry, @kueda! You seem to have gotten mixed up with my friend Shin-ichi. I shouldn’t post things after dinner.
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.
Yeah, I’m thinking of the occasional ones I see with accuracy circles spanning multiple time zones
I think that would be hugely helpful, in addition to being able to get coordinate-based time zones.
Just adding an example use case where manual or automatic conversion between time zones would be very convenient:
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.
The lizard is 8:27 PM GMT and certainly wouldn’t have been 8:27 PM local time.
That would be useful in the case where you discover your camera has the wrong time after taking lots of photos.
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?
Yes, it’s the same time zone shown for everyone.
Yes, the time and time zone can be edited by the observer, but they are accurate without editing, and anyone can see the time zone that the observer was using to state the time.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.