Search results list observations in the wrong order

Platform: website

Browser: Chrome, Firefox

URLs of any relevant observations or pages:

Description of problem:

In the above listing, the order of observations is incorrect. The first ten observations (added on June 8, 2020) are ordered correctly. The last two observations (added today) are not ordered correctly.

Note that the ten observations added on June 8, 2020 have an observed date in the Atlantic Timezone while the last two observations (added today) have an observed date in the Eastern Timezone. This appears to be related to (if not the source of) the issue.

This is not an isolated issue. I’ve been going through my old observations from 2020 and noticed this earlier. However, I can not say it consistently happens every time. I’ll see if I can find an example where the correct order is maintained despite differing timezones.

So, they weren’t in different timezones in reality? Do you have a set time zone in your account settings? If not, website chooses quite randomly which one applies to your observations, so setting will save you from that issue.


My account is set to the Eastern Time zone but it wasn’t always that way. I didn’t realize there was such a setting when I first created my account in 2018, so for a long time I had no default. I remember changing this some time back but I don’t remember exactly when.

1 Like

Then you will need to manually change timezones on those observations, I’m not sure if there’s an easy way to filter those out.

Here is another anomaly. Consider the 8th and 12th observations from the ordered list:

Here are the corresponding observed dates from photo metadata:

2020-06-07 13:40:17 -0700
2020-06-07 13:43:18 -0700

So the photos were taken just 3 minutes apart, and therefore the two observations should be listed one after the other in the search output. However, the timezone offset in photo metadata is incorrect. The correct timezone is Eastern Time (-0500). I doubt this is the source of the issue but I wanted to mention it anyway, just in case.

For sure it’s timezones, list is going in the order of actual time, no matter which zone, so if one zone has 3p.m. later than the other it will be shown after 3p.m. of the second timezone which happened before.

1 Like

I hate to say it but this is a bug. It’s impossible to find duplicate observations under these conditions.

i don’t see a bug here. unless anything changes, i believe that when you upload via the website,

since you changed the time zone in your account settings between the 2 uploads, you got two different time zones applied to your observations. it’s definitely a quirk, but i think this is technically how the system was designed to work.

i think the best course of action in this case is just to fix the times whichever observations reflect an incorrect time.

it may also be worth noting that there’s a feature in the upload page that will allow you to offset times. not sure if that helps in this case, but it might help in future uploads.


I don’t doubt the system was designed to work this way. The bug is that the system defaults to some unspecified timezone if there is none specified in the user’s account settings. The system shouldn’t let me create any observations until I’ve specified a default. Otherwise this is what happens.

I find this “feature” to be a strange one indeed. @jdmore says it best:

See: Add time zone chooser to the web uploader

i think your account should always have a default time zone specified. whether it is assigned correctly initially or not (or how it should be assigned) is another question, perhaps. currently, i think it works as described here:

if that’s a bad workflow, maybe the best thing is to propose a better workflow in a feature request?

or if you just want to change the basis for time zones added to observations, then maybe that’s covered by (unless you have a different proposed workflow)?

Maybe it’s so now, but I had both UTC+0 and HST zones on my first observations, and those are zones I see in others’ observations, even new ones I think (rarely people edit the setting and mostly don’t respond to comments about it).

in the case of HST (or whatever the successor issue is now), i think that’s addressed in a separate bug report:

in the case described in this thread, the time zone is ADT. i suppose it’s possible that ADT an earlier version of the HST problem, but i don’t see a lot of cases of ADT. so i assume it’s unrelated. even if it’s related, the issue is already covered in the HST bug report.

regarding UTC, i see that you mentioned you had a lot of observations set to UTC (, but i don’t remember if anyone had actually worked out what causes UTC, other than perhaps someone defaulting their account setting default to UTC?

An account created via the website should have a default timezone determined by the timezone of the machine. However, accounts created via the apps default to null/UTC – this is a known bug that I assume will be fixed with the complete re-writing of the app. If someone with an account set to null/UTC goes to the website, the account timezone can get set incorrectly to something else – it used to be HST, now it’s different depending on the timezone of the machine you’re using at the time.


okay. so then whatever bug is described in this thread is already covered by your previous bug report (, right? (merge?)

I’m not sure that bug fully explains what’s going on because I don’t think the account could have gotten accidentally set to anything except HST prior to the account settings redesign, and the sample observations with ADT come from before then…

I think the summary here is:

  • it’s unclear how the account was set to ADT in the past, but it’s correct now
  • the observations with incorrect time zones can be (painstakingly) batch updated
  • if they are not updated to the correct time zone, then they will continue to sort “incorrectly” because iNat has no way of knowing the time zone is wrong – this is not an issue the developers can fix
  • there is still a known bug with the apps, which will probably be fixed when the new app is released
  • there is also a planned feature for auto-assigning timezones in the web uploader based on location that will hopefully mitigate future issues like this
  • improved onboarding is on the agenda, which would probably also prevent similar issues

If there are steps to reproduce the incorrect account time zone, that can be further investigated. Otherwise, there isn’t much to do.

1 Like

I didn’t create an account via app, but I use Facebook to log in, if it can make a difference in how time is managed.

Yes, this doesn’t appear to be a bug. I’m going to close the topic. Thanks for the excellent summary @jwidness.

I agree this is the best thing to do. That way the time zone would be correct, even if one’s camera is not set to the correct time (which iNaturalist has no control over).

1 Like