Cell/wifi catalog has entries with "impossible" dates

[mvglasow]

What steps will reproduce the problem? Download the current cell/wifi catalog and run the following query: select * from cell_zone order by created_at asc;

What is the expected output? What do you see instead? I'd expect the top entries in the list to have a created_at date from the early dates of the project. Instead I see:

• slightly over 30 entries created at various dates in the 1370s (didn't know they had cell phones in medieval times :-)
• then some 1300 entries dated 1970-01-01 (start of epoch, still 22 years prior to the launch of the first GSM network)
• three entries dated 1980-01-06
• then, finally, currently in row 1343 of the result set, the first cell with a feasible-looking date (2009-05-01)

What version are you using? On what operating system? Catalog dated 2016-03-24 (seems there haven't been any updates in the last week)

Please provide any additional information below. I didn't investigate wifis but there might be similar issues. Not sure what is the best way to deal with missing/implausible timestamp: some cells have equally weird timestamps for their last update, thus discarding data with a bogus timestamp may discard otherwise valid data. One option would be to set any obviously faulty timestamp (anything prior to project launch) to NULL. Another would be to use the earliest valid-looking timestamp instead of the bogus one (falling back to NULL if all timestamps are bogus).

[TjrGithub]

Possible cause: Someone rebooted their phone without a data connection while mapping. Cyanogenmod cannot write to the hardware clock on my model, so any reboot warps it into the 1970s. I suspect other people may also have this issue.

Suggested fix: when importing data on the server, impossible capture dates should be set to the import date.

[wish7code]

Suggested fix: when importing data on the server, impossible capture dates should be set to the import date.

ACK, makes perfect sense.

Neverthless without having looked into the data in detail, I suspect that this is not an Android issue, but artifacts from the outdated OpenMoko client. If I remember correctly the OpenMoko client uploaded dates in UNIX format instead of YYYY-MM-DD format.