Automatic time zones?

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.

3 Likes

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?

2 Likes

Yes, it’s the same time zone shown for everyone.

2 Likes

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