Working with timestamps in the live track API is kind of hard because they are offset since midnight UTC of the day the flight started (If I understand correctly).
However I think it would be more convenient to have the API returns the full timestamps to start with.
Would you accept a PR that change the API to return full timestamps ?
Of course clients would need to opt-in to keep them backward compatible. The two way I can think of is either by using a query parameter (they are already used to pass the lastUpdated timestamp) or by using an HTTP header.
I tried to implement a half-way solution (in draft PR #2071) that adds the timestamp of the first fix to the API response. It could help but would still requires arithmetic to comput the timestamp of every single fix which sounds half backed to me.
I mostly only tried to do this change to understand the code better and how to test it.
I must say I haven't found a good way to test this. It seems that there is no unit tests for the live track API ?
If you think that returning full timestamps might be helpful, I would love to contribute this change to skylines. I only need some guidance on the best way to:
opt-in (query parameter or header or ?)
test the change.
There might also be other place to change beside the live tracking API ?
My goal is to integrate the skylines live tracks into flyxc.app which only support spot & inreach trackers as of today
vicb
commented
4 months ago
Working with timestamps in the live track API is kind of hard because they are offset since midnight UTC of the day the flight started (If I understand correctly).
It seems like it is possible to get back to full timestamp in seconds by mirroring the logic in https://github.com/skylines-project/skylines/blob/c55ffa4d268d308b3ad8259516abaaa4267674c8/skylines/tracking/server.py#L89-L104.
However I think it would be more convenient to have the API returns the full timestamps to start with.
Would you accept a PR that change the API to return full timestamps ? Of course clients would need to opt-in to keep them backward compatible. The two way I can think of is either by using a query parameter (they are already used to pass the
lastUpdatedtimestamp) or by using an HTTP header.I tried to implement a half-way solution (in draft PR #2071) that adds the timestamp of the first fix to the API response. It could help but would still requires arithmetic to comput the timestamp of every single fix which sounds half backed to me.
I mostly only tried to do this change to understand the code better and how to test it.
I must say I haven't found a good way to test this. It seems that there is no unit tests for the live track API ?
If you think that returning full timestamps might be helpful, I would love to contribute this change to skylines. I only need some guidance on the best way to:
There might also be other place to change beside the live tracking API ?
My goal is to integrate the skylines live tracks into flyxc.app which only support spot & inreach trackers as of today