Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Have the tracking API returns full timestamp #2075

Open
vicb opened this issue Jul 30, 2020 · 1 comment
Open

Have the tracking API returns full timestamp #2075

vicb opened this issue Jul 30, 2020 · 1 comment

Comments

@vicb
Copy link
Contributor

vicb commented Jul 30, 2020

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

# import the time stamp from the packet if it's within a
# certain range
time_of_day_ms = data[1] % (24 * 3600 * 1000)
time_of_day_s = time_of_day_ms / 1000
time_of_day = ms_to_time(data[1])
now = datetime.utcnow()
now_s = ((now.hour * 60) + now.minute) * 60 + now.second
if now_s - 1800 < time_of_day_s < now_s + 180:
fix.time = datetime.combine(now.date(), time_of_day)
elif now_s < 1800 and time_of_day_s > 23 * 3600:
# midnight rollover occurred
fix.time = datetime.combine(now.date(), time_of_day) - timedelta(days=1)
else:
log("bad time stamp: " + str(time_of_day))
fix.time = datetime.utcnow()
.

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
Copy link
Contributor Author

vicb commented May 17, 2024

Any thoughts on this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

1 participant