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.
1 Like
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
Case in point:
https://forum.inaturalist.org/t/how-to-batch-correct-times-on-observations-for-incorrect-clock/10010
2 Likes
I made this feature request a while ago, in case you want to vote/comment on it: https://forum.inaturalist.org/t/add-time-zone-chooser-to-the-web-uploader/3096
Hmmm, looks like I already did comment on it.
1 Like
Or anyone else!
1 Like
I am totally with @kueda on this. Itâs INFURIATING that iNat defaults to specifying the time zone that Iâm in when uploading (Mac desktop web) rather than the time zone that the obs was made in. I have to go back and change each obs one by one and it wastes a huge amount of time.
Can the uploader not just use the co-ordinates of the obs and default to that timezone and specify the nearest city in the list???
1 Like
Was anything pushed for this? I just noticed all my iPhone obs from Texas with correct times were applied with PST.
1 Like
Nope. Still pending UI changes to the Uploader to address the concerns aired above.
OK, this has now been released. All newly created observations will now be assigned a time zone automatically, based on their true coordinates (and without taking accuracy/precision into account). The same goes for editing existing observations - if the observationâs coordinates are changed at all, it will automatically be assigned a time zone based on the new coordinates.
As part of this update, weâve removed the ability to manually edit the time zone for observations as well; youâre just responsible for adding accurate location and local time of day information. The system will take care of the time zone.
While this doesnât solve every potential issue with times, it should prevent two of the major issues on iNat when it comes to time zones:
-
Assigning a time zone to an observation based on the observerâs account time zone, which many (most?) people forget to change when they post photos from their travels.
-
Mislabeling time zones that we get from some apps, which is currently an issue in iOS.
Thereâs also a Offset Time tool in the uploader, which has been there for a while now. That should help if you forgot to update your cameraâs clock after a time change.
If you find any bugs, please start a topic in #bug-reports.
2 Likes
Does it take in account time zone of camera? If people donât change time when they travel, will it change time or just add a local time zone?
No, as mentioned above we havenât used time zone data from cameras and weâll continue to not use it. We now just use observationâs coordinates to apply what should be the correct time zone for that area. The system doesnât take into account the time of day of the observation, which of course could be wrong if you donât change your clock. But as @kueda mentioned above, at least the error should be isolated to the time of day the observation has, not its time zone.
1 Like
This doesnât really solve the whole problem, it just shifts it from one side to the other. So now one side works as intended, but the existing part is now broken.
It should always take the camera timezone metadata before anything else, as those times at least match their timezone. Assuming the timezone means if it isnât actually matching, you now have a bunch of observations with incorrect hours attached to them.
Phones were the only case where time zone needed to be forced, as there was an existing glitch there.
1 Like
Correct, it was never meant to solve the whole problem, just assign the proper time zone based the observationâs coordinates to reduce or at least isolate the problem(s) here. We canât know how correct or incorrect the photoâs time of day EXIF is, but we can be pretty certain which time zone the observation was made in based on its location. And thereâs an offset tool in the uploader page so the observer can make any last minute changes before uploading.
I agree we could potentially do more in the uploader to alert users about discrepencies between time of day and time zone, perhaps thatâs something to explore further. But I think this is a step in the right direction and should reduce or mitigate a lot of errors without adding more pop-ups and complications to the upload process.
Not necessarily, when it comes to Daylight Savings Time. I recently shot an event with a few other photographers. When we shared our photos to a Google Photos album, we all had the right time of day but the time zones in our cameras were different because some of us hadnât changed them for DST. So the photos appear all out of order (which is pretty annoying, haha).
And as others have said, not all cameras include time zone data.
Android has been pretty good for a while, as far as I know. It was iOS that was having problems recently, which we fixed (the app was sending the correct UTC offset) although it introduced more problems when the server tried to assign a time zone to the UTC offset. Hence my obserations in California which were -7:00 UTC were being given an MST time zone, for example. The automatic time zones functionality should now remove those potential problems from our mobile apps and our devs can focus on other things.
1 Like
So this will make all of my observations outside of my time zone have the wrong time from now on, because I am definitely not changing the time on all my cameras every time I change a time zone.
I still donât understand why it would hurt so much to use the complete time information from the camera - time+zone identifies a specific moment in time and thatâs what matters, âhaving a correct time zoneâ is a pointless goal.
Not necessarily, when it comes to Daylight Savings Time. I recently shot an event with a few other photographers. When we shared our photos to a Google Photos album, we all had the right time of day but the time zones in our cameras were different because some of us hadnât changed them for DST. So the photos appear all out of order (which is pretty annoying, haha).
I guess the difference is that this is usually user error, not technical/import error. I can easily identify incorrect time zones on my observations based on what time zone was imported from the camera just by glancing at the observations. For instance, seeing PST on Australian photos, so I know exactly what needs to be fixed. But thatâs no longer possible anymore since everything is assumed to be right and displayed with the local time zone. In all cases I think itâs more helpful if a provided time zone (from a camera) is taken. The new change only seems to mostly benefit iOS where there were issues taking the local time zone. But thatâs a specific issue that can be addressed on its own, it feels.
And as others have said, not all cameras include time zone data.
So it seems easy to adjust whether a time zone is provided or not. If it isnât, then the site can just assume the local time zone.
2 Likes
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.