Explicitly normalize timestamps for CvsTrackService to use UTC timezone

Oscar Tovarrequested to merge
otovar/use-utc-times-to-track-cvs-service into master

What does this MR do and why?

It's possible that someone may configure the timezone for a GitLab installation. In such cases, Time.current.iso8601 will return a string with a timezone that will not pass the Snowplow event schema which expects a timestamp string that's 20 characters long.

This didn't affect users in any negative way, but it did result in us throwing away these helpful metrics, so I used a priority4 for this. The fix itself isn't complex, so I fixed it early even with the priority4 label.

References

See https://gitlab.com/gitlab-data/analytics/-/issues/23964#note_2528947112

How to set up and validate locally

  1. Remove .utc from the current_time method.
  2. Focus the captures the error and count the failure in internal metrics and tracks an event for the scan examples.
  3. Run tests and verify that the diff points to a 25 char string that includes the timezone
  4. Add back the .utc chained method call to current_time and re-run the specs
  5. Verify that the tests pass now because it normalized to the UTC string which is 20 chars long.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Merge request reports