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.

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.

1 Like

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