[OSM-dev] Changeset metadata timestamps out of sync?

Jochen Topf jochen at remote.org
Mon Aug 15 08:03:03 UTC 2016

On Tue, Aug 02, 2016 at 04:35:43PM +0200, Martin Raifer wrote:
> I noticed that the timestamps in the changeset metadata doesn't
> exactly match the timestamps of their created, modified or deleted
> data in some recent changesets. In the affected changesets, the
> timestamps of the data objects are a couple of seconds earlier than
> the reported changeset-opening times. This shouldn't be possible,
> right?
> For example, the website reports that changeset 41146302 is opened at
> "2016-07-31T14:13:42Z", but it's node has a timestamp of exactly 4
> seconds earlier: "2016-07-31T14:13:38Z" (the API reports the same
> numbers, see http://www.openstreetmap.org/api/0.6/changeset/41146302
> vs. http://www.openstreetmap.org/api/0.6/changeset/41146302/download)
> Here are a few more examples of affected changesets:
> * http://www.openstreetmap.org/changeset/41192003
> * http://www.openstreetmap.org/changeset/41190900
> * http://www.openstreetmap.org/changeset/41190815
> * http://www.openstreetmap.org/changeset/41146301
> * http://www.openstreetmap.org/changeset/40490989
> I've checked a few samples, and it looks like as if about 20-25% of
> recent changesets are affected, but none if looking back more than a
> couple of weeks (the last example above was about the earliest
> affected changeset I could find).
> Now, unfortunately this small mismatch interferes with some data
> analysis tools that rely on precise timestamps, for example achavi
> (https://github.com/nrenner/achavi).
> Does anyone have a clue what could have caused this?

I looked into this and the problem is much worse. Using the latest changelog
and planet dumps I found over 200,000 changesets that have objects in them
with timestamps outside the time range given in the changeset. This problem
has been going on for a long time, but seems to have gotten much worse

#changesets year
    301 2009
    109 2010
  39463 2011
    363 2012
    139 2013
    278 2014
    119 2015
 161370 2016

I looked into the created_by tags of the changesets and they are all over. So
it is not related to any specific editor.

The code I used to check this is here: https://github.com/osmcode/osm-data-validation
The output of this program is available here:


Those files contain all the changesets and the data, respectively, that fails
the check.

Jochen Topf  jochen at remote.org  http://www.jochentopf.com/  +49-351-31778688

More information about the dev mailing list