We should including timing information in all events submitted by the Metrics Platform Client by default. This will allow Product Owners/Analysts to answer questions like the following without further intervention from a Software Engineer:

• How long does it take for users to interact with an element?
• How long does it take for an element to be seen?
• How long does it take for the user to complete a workflow?
• …

We could not calculate this from either the event.client_dt or event.meta.dt properties. The former is unreliable (see T259373: Develop strategy for mitigating degenerate client timestamps in event data). The latter is reliable but we would have to send at least one additional event per stream to determine an origin from which to measure.

All Grade A browsers support the High Resolution Time API (Performance.now()), which provides an high-ish-resolution timestamp "not subject to clock skew or adjustments" relative to Performance.timeOrigin.

Open Questions

1. Is there an equivalent API for Android and iOS?

Android: SystemClock.elapsedRealtime()
iOS: mach_continuous_time()

Acceptance Criteria

• The time origin for each platform is chosen
  • JS: Performance.timeOrigin
• The JS MPC includes timing information in submitted events
• The PHP MPC includes timing information in submitted events
• The Java MPC includes timing information in submitted events

Required

• Unit tests
• Integration tests
• Documentation
  • In-schema; and
  • https://wikitech.wikimedia.org/wiki/Metrics_Platform/Event_Schema (or similar)
• Passed QA?