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.
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.
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:
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?
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 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.
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.
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…
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.
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).