1141063 - Jobs last_modified should be returned as a unix timestamp, not an ISO formatted date

Status: RESOLVED WONTFIX

(Tree Management :: Treeherder: API, defect, P4)

Description

[Ed Morley [:emorley]]

In bug 1097090, we switched to only requesting deltas of jobs changed since the last request, so the UI didn't request all jobs every time. 

However the UI makes its own timestamp to use for the API call, rather than relying on a server provided value. This results in subtle bugs like that fixed by bug https://github.com/mozilla/treeherder-ui/commit/053be84cebcc0ef05b0140b5d5c802359dd9fc5d and I suspect might also be the cause of bug 1136869 (different vagrant vs server times). It also means we have to do things like subtract 3 seconds from times "just in case":
https://github.com/mozilla/treeherder-ui/blob/e64e0e100ed5ef0e88f7aa43c997a2328e0f6552/webapp/app/js/models/resultsets_store.js#L843

I think it would be less fragile if we instead did something similar to what Bugzilla's REST API does - and that's return a a server timestamp in each REST response, which can then be stored as is, and passed back to the API in the next request.

Comment 1

[Mauro Doglio [:mdoglio]]

I think we should rename this bug to be about returning the last_modified attribute as a timestamp instead of a ISO formatted date.
A ISO formatted date is the default representation of a TIMESTAMP field type in MySQL, which is required if you need an auto-generated last_modified column.
The code there accounts for a 3 seconds error margin because we are running the first batch of job requests in parallel. Those 3 seconds should fill the gap between the max(last_modified) of the first request and the max(last_modified) of the last one.

Comment 2

[Ed Morley [:emorley]]

I'm happy for the server to return in whatever format you think is best - my main wish is for us to use server time, not client time when saving the last modified for the next request. It is my understanding that the current implementation saves the client side with some fudging for timezone difference.

Comment 3

[Mauro Doglio [:mdoglio]]

The last_modified timestamp stored is the max returned by the service. The only manipulation done on the client (+'Z') is to tell the Date constructor to make it UTC instead of local time.

Comment 4

[Ed Morley [:emorley]]

Ah ok I misunderstood :-)