Possible date/time Unix Epoch issue with Samsung phones

Description of problem
I’ve noticed a handful of recent observations being uploaded with the observation date Dec 31, 1969 7:00 PM EST (or whatever the timezone offset). I suspect it is due to particular Samsung models or app version.

**URLs **:
These are examples in Michigan, all with the EST timezone offset:
Same goes for California:

This is generally a sign of a null or zero value in a date that counts from the Unix Epoch time. I started notifying people of their inaccurate date, and often pointed them to the photo data to get the correct date/time. While doing that I realized every single on of these I’ve looked at have this in common: They are all taken on a Samsung phone. Looks like mostly Samsung Galaxy S10e.

So I started looking at the model and software version, here are some:

SM-G970U1 G970U1UES4ETI1

It seems these inaccurate date observations on Samsung phones started occuring in late September:

This is beyond me at this point, but I think it is likely a bug for some model or software version of iNat on Samsung.

Steps to recreate
I have not personally had this issue, but some people seem to have reoccurring issues. @andrew54 and I were messaging and they indicated it happens inconsistently.

Related potentially: https://forum.inaturalist.org/t/dates-all-reset-to-dec-31-1969/16813

Looks like the GPS date stamp is “01/01/70” and the GPS time stamp is “[(0/1), (0/1), (0/1)]” - bizarre.

1 Like

Yes, that seems to be the case for most of these Unix Epoch dated observations.

I’ve encountered this same issue with a subset of Lepidoptera observations in Texas that I have been compiling:
All are from Samsung products. I didn’t collect software versions, but additional models within this subset, not mentioned by @dooug above, include:


I had begun to go through these observations, add a comment about the wrong observation date/time, requesting it be corrected and voting “No” on the DQA “Date is accurate?”
But is there some way on iNat’s end to correct such observations en masse by reading the actual creation date rather than that erroneous GPS date?
This data set with erroneous observation dates is screwing up some historical overviews of observations I’m trying to compile.


The number of erroneously dated observations is substantial and probably increasing rapidly:
The above search (as of 1/3/21 1:30 PM CST) finds nearly 3,500 observations with bad dates. Probably only the first half dozen of that set (earliest ones by upload date) are correctly dated Dec. 31, 1969. All the remainder appear to be fallacious, even though metadata on many of the 2019 uploads do not include the source equipment or model.

1 Like

Lol, it is up to almost 5k observations observed on Dec 31st, 1969! https://www.inaturalist.org/observations/identify?quality_grade=needs_id%2Cresearch&on=1969-12-31&photos=true

This was addressed in https://github.com/inaturalist/iNaturalistAndroid/commit/55689abec1ca85725a1c9a1e8f30d37d0cb9176a which should have been included in version 1.21.6 of the app (build 473). We still seem to be receiving observations like this from people who haven’t updated their copy of the app.

There’s not much to do about these other than to use the Data Quality Assessment and vote “no” in response to “Date is accurate”

That’s what I’ve been doing for a small subset of observations of interest to me. I may also add a polite comment under the observation. A large proportion that will remain uncorrected are those by casual iNat users (students or CNC only) who use Samsung products but haven’t returned to iNat.
I think I also noticed a spike of unintended dates for “January 1, 1970”. I assume staff has the tools to at least recognize these likely bogus observation dates? I would be interested in seeing a small list of the most frequently seen erroneous dates.

1 Like

Is there any opportunity to semi-automate this process (there are still thousands of mislabeled observations, many of which are at GBIF) or assist users in any way?

In particular it can be a frustrating issue for users to fix the date since it’s not possible to type in a date on Android.

1 Like

Since I can’t determine which dates were caused by the bug and which were intentional, I can’t automate the fix for everyone. I can fix observations for individual users if they request it.