Add second level resolution

[bhelx]

Right now, we just say "less than a minute ago" because we were only getting minute level resolution from the server. But we can request second level with the tmres query paramter. So this updates the client to ask for second resolution and shows this to the user. It gives them a little more context on whether they are looking at live data or some kind of ghost vehicle. Instead of showing the exact number of seconds I'm rounding the number of seconds to the nearest 5 so we don't overexercise react.

Before

After

[chr1sto14]

I found out that the timezone parsing isn't very robust. The seconds division looks good, but the parsing section needs something like the following so timestamp show up correctly no matter the device timezone.

const timestamp = Date.UTC(
    ts.slice(0,4), // year
    ts.slice(4,6)-1, // month (0 based)
    ts.slice(6,8), // day
    ts.slice(9,11), // hour
    ts.slice(12,14), // minute
    ts.slice(15,17), // second
);
const now = new Date()
const utcDate = new Date(now.toLocaleString('en-US', { timeZone: 'UTC' }));
const nolaDate = new Date(now.toLocaleString('en-US', { timeZone: 'America/Chicago' }));
const offset = utcDate.getTime() - nolaDate.getTime();
const relativeTimestamp = now.getTime() - timestamp - offset;

[harveysanders]

Out of curiosity, what's the advantage of moving the time parsing to the client? Performance gains from less marshaling, unmarshaling? Doesn't this come at the cost of losing the Vehicle types and the built-in, battle-tested time parsing in go? With the time parsed to on the backend, couldn't you just pass the time string directly to the Date constructor and have the timezone sorted? Seems like less bug surface area.

Again, just asking questions to better understand the app to better contribute eventually :)

[chr1sto14]

The Go server pipes the API response data along to the client. All of the business logic is concentrated on the client now. I'm not sure about performance impacts.

[harveysanders]

Gotcha. Thanks!