KPI timestamp reported in milliseconds

[nmalkin]

One of the pieces of information stored in the KPI backend is the timestamp of the interaction (rounded to the nearest 10-minute interval). Right now, this is sent over (and stored) in milliseconds since the Unix epoch. Though this is standard for JavaScript, we may want to — for standardization — convert this to Unix time (i.e., seconds since epoch).

[shane-tomlinson]

@nmalkin - This is a good suggestion - in the end we actually want the timestamp stored in 10 minute resolutions - see PR #1670, more specifically #1670 (comment) where @lloyd suggests the rounding happen in the router.

[benadida]

review whole data flow /cc @benadida @shane-tomlinson @jedp

[nmalkin]

While #1784 rounded the timestamp to the nearest 10 minutes, the original issue (this one) was not addressed: the timestamp is still in milliseconds. @shane-tomlinson, do we have any plans to change it to seconds, or are we sticking with milliseconds?

[jrgm]

Verified in dev where kpi in on (data_sample_rate:1 in session_context). The server timestamp is rounded to the nearest 10 minute block.

Notes:

• this issue was opened about using epoch seconds not milliseconds and morphed into moving the logic for rounding the timestamp sent to /wsapi/interaction_data from the server to the client. The latter is done; @nmalkin if you feel strongly about epoch seconds, open a new issue (I'm not going to morph this back again ;-) ).
• this is a rounding (not a modulo truncation) to the nearest 10 minute slot so e.g., both 19:45:00 and 19:54:59 fall in the 19:50:00 slot (/wsapi/interaction_data was doing truncation).

[shane-tomlinson]

@jrgm - I can just as easily round down, is there one which would be of more use than the other?

@nmalkin - +1 to @jrgm's comment, if you want this in seconds, can you open another issue? We could take it a step further, save a few bytes, and chop off the last 5 digits which are all 0 because of the rounding to the nearest 10 minutes.

[lloyd]

I feel like it's slightly more ergonomic to have the timestamp be period start time. so the 10 minutes starting at time X.

I'm thinking that a common case will be looking at failure spikes and trying to correlate them to events. If I'm trying to understand the affect of an event that occured at 12:55, I look at the period of 12:50 and beyond.

my 2 cents on a nit, as @jrgm notes.

[jedp]

+1 for rounding down

[jrgm]

I was just noting the difference, and am fine with the current, but it appears rounding down is the cool kids preference ;-)