Adds cdt parameter to tracking query items

[notjosh]

Because of ✨reasons✨, the h/m/s values don't seem to be used in calculating "time on page" in the backend, but cdt does.

This PR attaches cdt to the tracking events in addition to the existing h/m/s values.

According to this issue, cdt will be used to calculate the "time on page" correctly for the clients, regardless of when they're sent to the server

According to these docs, the format is yyyy-MM-dd HH:mm:ss (i.e. 2011-04-05 00:11:42) - not quite ISO-8601, but close (although we could use a unix timestamp? They're always a little harder to grok for human eyes though). However (and this is an implementation detail, so probably best to ignore or update docs), the server uses unix timestamp internally, and processes it via strtotime(), so we could use a formal ISO 8601 date string here if we'd prefer. ➡️ Using ISO 8601 format since 2feaae1

---

Resolves #299

[brototyp-bot]

	1 Warning
⚠️	Are there any changes that should be explained in the README.md?

Generated by 🚫 Danger

[brototyp]

Hey @notjosh, this looks great! I am currently trying to get one of the backend developer to check if it's fine to send a "normal" ISO-8601 date along which I would like the most. If we don't hear back from them soon I am happy to merge it though. I'll get back to you within a day.

[notjosh]

Great! No rush though, I can use my branch for as long as necessary :)

[tsteur]

something to keep in mind... there is this setting:

; By default, Matomo accepts only tracking requests for up to 1 day in the past. For tracking requests with a custom date
; date is older than 1 day, Matomo requires an authenticated tracking requests. By setting this config to another value
; You can change how far back Matomo will track your requests without authentication. The configured value is in seconds.
tracking_requests_require_authentication_when_custom_timestamp_newer_than = 86400;

So if the cdt is older than one day and no token is specified, Matomo will throw an exception and not record the request. Don't know if there's a feature that eg sends tracking requests while the user was offline eg a day later... these would not be recorded then.

[tsteur]

I haven't tested ISO8601 string, timestamp should work well though.

[brototyp]

Thanks for your feedback @tsteur!

@notjosh, I guess I would change over to using a timestamp here. I would give "easier code" more weight than the "readability of the requests". What do you think?

[notjosh]

I was looking through the Android code for other reasons earlier, but it applies here:

So if the cdt is older than one day and no token is specified, Matomo will throw an exception and not record the request. Don't know if there's a feature that eg sends tracking requests while the user was offline eg a day later... these would not be recorded then.

and

I haven't tested ISO8601 string, timestamp should work well though.

Android is already attaching cdt to all requests, and is using a date format closer to ISO 8601 (though, it's different than the format documented).

Either it's ok to do that here, or it should probably be dropped from Android too, so we're not seeing inconsistent results across platforms.

@notjosh, I guess I would change over to using a timestamp here. I would give "easier code" more weight than the "readability of the requests". What do you think?

Is it really much different? It's still (presumably) to be hidden behind a DateFormatter helper, so the caller won't see any difference, and the formatter itself (using .dateFormat is fairly common?

Ultimately, I don't mind either way - I call the SDK, and you decide how to send those dates :) But at the moment it's fairly inconsistent across platforms, so it might be helpful to align those internally across teams.

[brototyp]

Hey @notjosh, I had a chat with the backend engineers. ISO8601 is fine. Let's change over there (if you are fine as well). I'll try to get the documentation updated in that regard.

[notjosh]

Hiya, I've bumped to use ISO 8601 date formatter (in 2feaae1).

It's trying to use ISO8601DateFormatter when it's available, which might add some complexity to the code you don't want - I'm happy to remove that if you'd prefer.

[notjosh]

Gentle bump. Any progress on this? Happy to maintain a fork (we need the functionality!) if it's a Bad Idea on your side though.

[brototyp]

Hey @notjosh, thanks for your patience. And thanks for the bump. I did forget about your PR here.
I am happy with your changes. Can you do me a favor and rebase it from develop, check the changelog (I think your editor replaced all bulletpoint - by *s)? Once the tests go though I'll merge through. This could then be part of the Swift-5 release.

[notjosh]

Oh, doh, you're right - Prettier bumped all the bullets. I rebased, fixed the changelog, and cleaned out the merge commit. Should be ok from my side, assuming tests are green

[brototyp]

Perfect. Thanks a lot!

[brototyp]

This just got released in version 7.0.0