Timestamps appear to be 60 seconds in the future

I am seeing that in the json object for each row the timestamps ("time_position") are offset 60 seconds into the future.

I see this result both in my own software and when I use an online epoch converter to convert the state data received as a json object from:
opensky-network.org/api/states

 So, for example, if I am querying the state at UTC 14:00:00, the state data reports time_position (index 3) values for each row to be within ~15 seconds of 14:01:00 UTC.

I do not know when this offset into the future started, as I had not been actively reviewing the data here for some months due to involvement with other projects.  I first noted this yesterday as I reinitiated work on a project involving querying the live database.

Is anyone else seeing this? 

Thanks in advance!

You can easily prove that this error is present by doing the following:

1. Copy the most recent timestamp contained in the jquery resulting from:
opensky-network.org/api/states/all?lamin...7.8229&lomax=10.5226

2.  Paste it into the textbox under the heading "Convert epoch to human-readable date and vice versa" at:
www.epochconverter.com/  (Obviously you need to have picked a "good" timestamp from the query and not a stale one).

3.  Click the "Timestamp to Human date" button next to the textbox into which you put the timestamp.

4.  You will see in the result, "Relative:  In a minute" indicating that the downloaded timestamp is approximately one minute into the future.
 
 

The incorrect time offset is a corruption of uploaded aircraft data that occurs at the level of the OpenSky server; it is not present in the time data that observers are uploading to the OpenSky server.

I confirmed this with the plane data that I upload to OpenSky.  The timestamps are correct on the plane data that I generate here and when that data returns to me from the OpenSky server, the time data returning from the OpenSky server has been corrupted, with the time offset into the future applied, so that the timestamps are no longer correct.

This is a major issue for those using the data in a manner that requires accurate timestamps, and it is an issue that should be quickly addressed.

Thanks for the reply! I noticed this issue first on June 22 of this year, but I had not been reviewing the data here for months due to involvement with other projects. So I cannot say when this started, unfortunately. It could have been well before June 22.

Thanks again and please let me know if I can provide further information.

Best Regards!

Thank you very much! I just did a spot check of the incoming data and time_position values now appear to be appropriate.

I very much appreciate the fix.

Thanks again, and thanks for a wonderful service!