If I could go back in time I would get rid of the meta subobject altogether. meta is currently defined in the primary fragment/common schema, and jsonschema-tools isn't so great at merging subobjects. So, to define your own meta, you'd have to make an entirely new meta in your fragment/analytics/common and copy/paste the needed fields from fragment/common and not reference the primary fragment/common one at all. I think it will be simpler if we make all schemas reference the same primary fragment/common schema, and any other 'common' fields be defined by a separate fragment schema, e.g. fragment/analytics/common.

Just had a discussion (prompted by other things) with Joseph and Nuria. If possible, we'd like to reject events that have meta.dt set to values too far from the current time. Since other events already use and set meta.dt to represent event time, we can't and shouldn't make eventgate always set it to receive time. We use meta.dt for the Kafka timestamp as well as the Hive hourly partitioning key. If meta.dt is way off, the event might be lost in raw data and never make it to refined Hive tables. I think we should be able to restrict the value off meta.dt using JSONSchema validation. Not sure, but we should try!

I suppose that's fair, although the follow-up question is how far is too far? We still would like events which are queued up and persisted, perhaps for up to a day or more, to make it into the database. If a mobile app user reads articles offline (via the reading list feature) for a week and then comes online at the end of the week, the app would start sending any events generated while they were offline. What happens to them? Which partition do they end up in?

Would you be okay with adding logic to EventGate to set a received_dt, then?

Ah, the rejection would only happen if the client sets meta.dt to something bad. If you leave it blank, eventgate will set it and it will effectively be receive time. You can still set event_dt to whatever you want! :)

@jlinehan @nshahquinn-wmf @mforns @Ottomata: Okay, so how do y'all feel about the following:

• Add event_dt as a top-level field in fragment/analytics/common schema
• Change EPC for iOS/Android and the MEP component of EventLogging to record event generation time in event_dt instead of meta.dt (ext.eventLogging/core.js#L129-L134)
• Document in code and in schema that meta.dt is left empty at log time in order to have EventGate set it, making it receive time

@EBernhardson: Hi!!! Just wanted to ping you and see what you thought about this proposal to have generated & received timestamps in analytics events via EventLogging core?

Makes sense to me!
Maybe I'd use another name for event_dt that explains how it is different from meta.dt?
Maybe client_dt?

@mforns I suggested event_dt in https://phabricator.wikimedia.org/T240460#6125463 mainly because that is what this is referred to in stream processing worlds. Also, client_dt might not make sense in other situations, like a syslog event or something. This field will be used to specify the time the event happened.

I agree though, having meta.dt sometimes be event time and sometimes the 'eventgate receive time' might get a bit confusing, but I don't think we can change meta.dt now. It is already being used as the event time for all of the EventBus sent mediawiki events. Also, if we can, we do want to use the event time as the Kafka timestamp and Hive partition timestamp, its just that in some cases where we don't trust the producers we can't be sure they will be setting event times that make sense.

Change 597617 had a related patch set uploaded (by Ottomata; owner: Ottomata):
[schemas/event/secondary@master] Add fragment/analytics/common schema

https://gerrit.wikimedia.org/r/597617

Although, on second thought, maybe client_dt is better here after all? Since this will be used only by analytics / instrumentation schemas, perhaps client makes sense? meta.dt is the default event time and will always be used for kafka timestamps and hive partitioning. Maybe client_dt is actually more descriptive for what it is being suggested for here.

@mpopov @jlinehan while working on some docs, I submitted https://gerrit.wikimedia.org/r/597617 so that my docs wouldn't be totally incorrect :p. Let me know what you think.

In T240460#6153784, @Ottomata wrote:

Although, on second thought, maybe client_dt is better here after all? Since this will be used only by analytics / instrumentation schemas, perhaps client makes sense? Maybe client_dt is actually more descriptive for what it is being suggested for here.

With @mforns preferring client_dt, myself preferring client_dt, and @jlinehan being more comfortable with client_dt than event_dt, it kinda looks like we should go with client_dt :P Updating patch to use that instead...

Ok let's do it.

Change 597617 merged by Bearloga:
[schemas/event/secondary@master] Add fragment/analytics/common schema with client_dt

https://gerrit.wikimedia.org/r/597617

Change 599899 had a related patch set uploaded (by Bearloga; owner: Bearloga):
[mediawiki/extensions/EventLogging@master] Record event generation time in client_dt

https://gerrit.wikimedia.org/r/599899

Change 599899 merged by jenkins-bot:
[mediawiki/extensions/EventLogging@master] Record event generation time in client_dt

https://gerrit.wikimedia.org/r/599899

Change 604147 had a related patch set uploaded (by Ottomata; owner: Ottomata):
[schemas/event/secondary@master] Make analytics/legacy/eventcapsule use analytics/common

https://gerrit.wikimedia.org/r/604147

@Ottomata: unless I'm mistaken your port of search satisfaction to MEP is the only way we have of seeing how this is working in production, right?

There is nothing using mw.eventLog.submit yet. Either the SearchSatisifaction port, or the session_tick event, whichever comes first :)

Change 604147 merged by Bearloga:
[schemas/event/secondary@master] Make analytics/legacy/eventcapsule use analytics/common

https://gerrit.wikimedia.org/r/604147

Hey all we need to revisit one decision here.

From: https://wikitech.wikimedia.org/wiki/Event_Platform/EventLogging_legacy#timestamp_field_semantics

The deprecated eventlogging server side would set the dt field to the time it received the event. This is no longer true once a legacy EventLogging stream is migrated to Event Platform. The new semantics are

• meta.dt - server side receive time (unless the client explicitly sets this field). This field is used for hive hourly partitioning.
• client_dt - client side date-time timestamp.
• dt - deprecated, but set to the same value of client_dt

dt is a legacy EventLogging field, but it is very likely that many people are using this field for analysis. By setting it to client_dt, this changes the semantics. In order to keep compatibility, I propose we default dt to the eventgate receive date-time, just like meta.dt This will keep it a server side receive timestamp (if it is not set by the client), just as it is in the deprecated eventlogging backend.

@mpopov @jlinehan @Mholloway @mforns @nettrom_WMF thoughts?

In order to keep compatibility, I propose we set dt to the same value of meta.dt in eventgate-wikimedia. This will keep it a server side receive timestamp, just as it is in the deprecated eventlogging backend.

Makes sense to me.

I updated my comment slightly, the proposal is to default it to the eventgate receive time (not the value of meta.dt). Most of the time meta.dt and dt will be the same, unless the client explicitly sets one or the other.

Change 639621 had a related patch set uploaded (by Ottomata; owner: Ottomata):
[eventgate-wikimedia@master] Default dt to now

https://gerrit.wikimedia.org/r/639621

In T240460#6607413, @mforns wrote:

In order to keep compatibility, I propose we set dt to the same value of meta.dt in eventgate-wikimedia. This will keep it a server side receive timestamp, just as it is in the deprecated eventlogging backend.

Makes sense to me.

+1

Change 639622 had a related patch set uploaded (by Ottomata; owner: Ottomata):
[mediawiki/extensions/EventLogging@master] Allow EventGate to default dt to server side receive time

https://gerrit.wikimedia.org/r/639622

If we decide to do this, these are the patches:

• https://gerrit.wikimedia.org/r/c/eventgate-wikimedia/+/639621
• https://gerrit.wikimedia.org/r/c/mediawiki/extensions/EventLogging/+/639622

@Ottomata One thing to be aware of (which slipped my mind) is that we plan to have the dt field be used for the *client-side* timestamp (today this is client_dt). The reason for this change is

• The client-side timestamp is the only intuitive data that would be in a top-level timestamp field, since it corresponds to when the event was generated.
• It is also the most diagnostically relevant for analysts, and hence should be afforded the prominence of a succinct, top-level field without qualifiers.

Therefore if we do set dt to be the server-side timestamp for these schema, we should be aware that those semantics are either a.) going to be different for new schema or b.) change at some point in the future for these legacy schema. So... I wonder if we shouldn't just have dt be the client-side timestamp?

The downside here is that before the migration, the timestamps will be server-side (legacy semantics), while afterwards, they will be client-side. We can explore whether this is a problem, though (@mpopov @nettrom_WMF @nshahquinn-wmf -- any thoughts?).

A couple words about the server-side timestamp since we're on this ticket -- while initially we dismissed any server-side timestamp as being of no value, what we've seen (especially on the apps) is that a server-side timestamp is really useful for helping us measure the delta between event generation time and event ingestion time, which tells us a lot of information about network conditions, how our buffers are operating, and how stale the data is.

Therefore I think we will continue to want both, it's just a matter of how they are labeled. In particular though, the server-side timestamp doesn't need to be hiding somewhere out of sight (as it arguably is in meta.dt). But we can tackle some kind of 'promotion' from meta.dt to a better-named field sometime down the road -- I understand that meta.dt is intertwined with the implementation of the pipeline in certain places.

hence should be afforded the prominence of a succinct, top-level field without qualifiers.

By qualifiers here you mean the 'client_' part?

while initially we dismissed any server-side timestamp as being of no value,

Server side timestamps are also necessary for backend processing, since client side timestamps can be arbitrarily set to something in the future or in the past.

In particular though, the server-side timestamp doesn't need to be hiding somewhere out of sight (as it arguably is in meta.dt)
is that we plan to have the dt field be used for the *client-side* timestamp

I'm not sure I understand the problem here. In all cases, the server side only defines these as defaults. If the client sets any of these timestamps, the server side won't touch it.

Why not just keep meta.dt being the server side timestamp (unless the client sets it), and client_dt being the client side event timestamp, and then keep dt around only for backwards compatibilty as a server side timestamp?

In T240460#6609647, @Ottomata wrote:

hence should be afforded the prominence of a succinct, top-level field without qualifiers.

By qualifiers here you mean the 'client_' part?

Yup!

while initially we dismissed any server-side timestamp as being of no value,

Server side timestamps are also necessary for backend processing, since client side timestamps can be arbitrarily set to something in the future or in the past.

Sorry, I should have clarified -- I mean 'no value' for the purposes of data analysis, i.e. we thought a client-side timestamp replacing a server-side timestamp was all we cared about. So, in other words, yes we have both client- and server, but when we didn't care about the server-side timestamp, the thinking was "if the system wants to stick a server-side timestamp on it, the semantics can be whatever it wants, and it can call it whatever it wants, because we won't be using it for analysis."

Now, though, we know that we are actually interested in server timestamps, so it would be nice if the server and client timestamps were both named in a nice, regular way and followed regular semantics. However this is kinda off topic for the point I'm trying to make, sorry.

I'm not sure I understand the problem here. In all cases, the server side only defines these as defaults. If the client sets any of these timestamps, the server side won't touch it.

Why not just keep meta.dt being the server side timestamp (unless the client sets it), and client_dt being the client side event timestamp, and then keep dt around only for backwards compatibilty as a server side timestamp?

We have three timestamp fields (dt, meta.dt, client_dt) with variable semantics, and we only need two timestamp fields with fixed semantics. Why not use this fix to kill one of the fields and go to fixed semantics? The field to go ought to be client_dt -- it's the ugliest, but it's also the only field that can go, since the legacy schemas will have a dt field. We probably should have just used dt to begin with, but that's hindsight.

Using dt for the client-side timestamp will clash with the legacy semantics of the dt field (where it's a server-side timestamp), but I don't think it matters. In a few months, nobody will even remember that it used to be server-side. From a design perspective, it makes more sense for the dt field to be, well, the timestamp of when the event happened, rather than rope it off as a legacy-only thing.

TL;DR - we should make the dt field the client-side timestamp, rip out client_dt, and keep using meta.dt as the server-side timestamp.

TL;DR - we should make the dt field the client-side timestamp, rip out client_dt, and keep using meta.dt as the server-side timestamp.

Hm. I'd be ok with this. And, I think we can get away with not changing legacy semantics. In the patch I made above, eventgate-wikimedia will only set dt if it isn't already set. So, in EventLogging JS, we can avoid setting it for legacy events (ones that come through mw.eventLog.logEvent), and it will remain as a server side receive timestamp. For new events (via mw.eventLog.submit), just set dt to the client's timestamp.

Although, for non-analytics events, meta.dt is not necessarily the server side receive timestamp: EventBus sets this as the 'event time', e.g. when a revision was created. Ideally we'd use the external client side event time for meta.dt as well, but we can't because we can't trust the external clients to always set a meta.dt that makes sense or will be accepted by the system.

client_dt is already baked into a few schemas though, and is the only field declared by the fragment/analytics/common schema. I don't mind changing this, but is it really worth it? client_dt is pretty descriptive, no? If we were starting from scratch I'd say ok, fine, dt is client side time, but we already have client_dt which seems fine to me too. Is it worth changing things?

In T240460#6610337, @Ottomata wrote:

client_dt is already baked into a few schemas though, and is the only field declared by the fragment/analytics/common schema. I don't mind changing this, but is it really worth it? client_dt is pretty descriptive, no? If we were starting from scratch I'd say ok, fine, dt is client side time, but we already have client_dt which seems fine to me too. Is it worth changing things?

Yeah... these more basal schema / fields are going to have a long life (hopefully) and so decisions we make now will have a large impact, so it's worth it to me to adjust as much as possible while we have as few schema as possible and can manually intervene. There are some other things we're doing as well that are going to require adjustments to the few analytics schema that are out there, so it's in the same line with that. At the moment all of the analytics schema are either running side-by-side with a legacy schema (apps) and can have their table dropped, or are legacy migrations. The legacy migrations might have extra fields (e.g. client_dt) hanging around for a while, but after the migration, we'll gradually be upgrading these to use new patterns and stuff, so the old tables will probably be tossed or archived, anyway.

Yeah... these more basal schema / fields are going to have a long life (hopefully) and so decisions we make now will have a large impact,
The legacy migrations might have extra fields (e.g. client_dt) hanging around for a while, but after the migration...

I find it very unlikely that we will disable all legacy EventLogging streams anytime soon. I'd predict that some of these will be online and necessary for many years to come. If that is true, and we choose to make dt a client side timestamp for only new schemas, but leave it as a server side timestamp for legacy EventLogging schemas, won't we cause some confusion for a long time to come? Your points I quote here make me think that keeping client_dt as the official client side timestamp is the right thing to do.

But! I don't care that much! @mpopov you were originally proposing client_dt here, any thoughts?

In T240460#6614179, @Ottomata wrote:

Yeah... these more basal schema / fields are going to have a long life (hopefully) and so decisions we make now will have a large impact,
The legacy migrations might have extra fields (e.g. client_dt) hanging around for a while, but after the migration...

I find it very unlikely that we will disable all legacy EventLogging streams anytime soon.

I'm not talking about disabling legacy streams, I'm pointing out that we have plans, after migrations, to update many of these in a more comprehensive way that will likely result in alterations to their tables. Alterations that are extensive enough that for many of them, it is likely that they will receive an entirely new table, and the old one will be archived, or discarded. My point here is that if we discontinue use of client_dt, it will live on in these tables as a zombie field but it's fine.

In T240460#6614179, @Ottomata wrote:

If that is true, and we choose to make dt a client side timestamp for only new schemas, but leave it as a server side timestamp for legacy EventLogging schemas, won't we cause some confusion for a long time to come?

No, that is not what I'm saying. As of the merging of whatever patch we make, dt is the client-side timestamp for all analytics events, all the time. meta.dt is the server-side timestamp for all analytics events, all the time. Never the twain shall meet.

We will update the new-style client code path to set dt rather than meta.dt, allowing EventGate to set the server-side timestamp. We need to make changes to the analytics base schema to add a dt field, which is happening right now as part of a related effort to align schema practices. The patch you're working on can update the legacy code path to set the dt field to the client-side timestamp, and not set meta.dt. Maybe the problem your having is that you can't stop the submit method from setting meta.dt. We can jam on a workaround or just wait until the new schema with dt come online.

Ok! Just discussed with Jason and I'm convinced. If we are going to do this right once and for all, we need to do it right for ALL events, not just externally emitted instrumentation events. This means for EventBus events too. Here's the plan:

• dt is always a client AKA event timestamp.
• meta.dt is always a server side receive timestamp.
• Which timestamp field is used for Kafka index and Hive partitioning is configurable.

Right now, meta.dt is always used for partitioning. In an ideal world we'd always use the client's event timestamp. However, an external client might send any timestamp value, even one years in the future, so we can't trust them! So, we need to vary which timestamp we use for this, and since we have different EventGate instances and also Camus-HDFS ingestion jobs for different EventGate instances, we can configure those things appropriately:

• eventgate-*-external instances will use the server side meta.dt timestamp for partitioning (since we can't trust the client's dt in this case for that), but fall back to dt if not meta.dt is not set.
• All other instances will use client event dt timestamp for partitioning, but fall back to meta.dt if not set.

This is easy to do now for the instrumentation events. To do it for production MediaWiki events, we need to update EventBus and related schemas:

• Add a dt field to all schemas.
• EventBus should set dt, but not set meta.dt, which will allow EventGate to set it.

IIRC, some events do not use EventGate, they produce directly to Kafka. Those producers should set dt instead of meta.dt.

These changes should be relatively unnoticeable for users of MediaWiki production events, as the difference between the client and server receive timestamps will usually be miniscule.

@Pchelolo let me know what you think, and if we should discuss further. We're going to proceed with this plan for analytics events soon, but we can make the EventBus related changes at any time later.

Oh, @jlinehan for legacy EventLogging events, we then will make EventLogging JS not set dt, making it actually be a server side timestamp for the legacy events, right? The semantics of dt will change, but only for new instrumentations, not for existing event data, correct?

eventgate-*-external instances will use the server side meta.dt timestamp for partitioning (since we can't trust the client's dt in this case for that), but fall back to dt if not meta.dt is not set.

Is it wise to fall back to untrusted dt? wouldn't it be better to use current time as fallback?

@Pchelolo let me know what you think, and if we should discuss further. We're going to proceed with this plan for analytics events soon, but we can make the EventBus related changes at any time later.

In general - yeah, makes sense. I'm in doubt about naming... meta.dt vs dt is not a very obvious distinction, but without renaming existing meta.dt I can't come up with a better naming scheme. Would've been awesome if it was like meta.event_dt and meta.receive_dt or something... Not proposing to do it, just rambling. With good documentation it would be ok to have just dt everywhere.

Is it wise to fall back to untrusted dt? wouldn't it be better to use current time as fallback?

Hmmmm actually I started writing that originally but then thought it would cause problems. On second thought...yes. Both EventGate and Camus can fall back to current time if the field is missing.

Ok @jlinehan @mforns I updated my patches for legacy dt, please review:

• https://gerrit.wikimedia.org/r/c/eventgate-wikimedia/+/639621/5
• https://gerrit.wikimedia.org/r/c/mediawiki/extensions/EventLogging/+/639622

@jlinehan, I'll let you or @Mholloway make the changes for non legacy schemas to use dt instead of client_dt. This will require schema changes for any of the existing schemas, and also a change to mw.eventLog.submit to set dt instead of client_dt, but shouldn't require any changes to eventgate-wikimedia.

I'll make a low priority subtask for modifying EventBus events and ingestion code to use either meta.dt or dt as stated above.

In T240460#6616381, @Ottomata wrote:

@jlinehan, I'll let you or @Mholloway make the changes for non legacy schemas to use dt instead of client_dt. This will require schema changes for any of the existing schemas, and also a change to mw.eventLog.submit to set dt instead of client_dt, but shouldn't require any changes to eventgate-wikimedia.

Yep, willll do!

Change 639621 merged by Ottomata:
[eventgate-wikimedia@master] Default dt to server side receive time for legacy EventLogging events

https://gerrit.wikimedia.org/r/639621

Change 641266 had a related patch set uploaded (by Ottomata; owner: Ottomata):
[operations/deployment-charts@master] eventgate-* - Bump eventgate-wikimedia version to 2020-11-16-212345-production

https://gerrit.wikimedia.org/r/641266

Change 641266 merged by Ottomata:
[operations/deployment-charts@master] eventgate-* - Bump eventgate-wikimedia version to 2020-11-16-212345-production

https://gerrit.wikimedia.org/r/641266

I've deployed the eventgate-wikimedia change in all staging clusters. I'll do the prod ones tomorrow. If that all looks good I'll merge the EventLogging change and schedule it for a backport window...or just wait for the train.

Change 639622 merged by Ottomata:
[mediawiki/extensions/EventLogging@master] Allow EventGate to default dt to server side receive time

https://gerrit.wikimedia.org/r/639622

Change 641799 had a related patch set uploaded (by Ottomata; owner: Ottomata):
[mediawiki/extensions/EventLogging@wmf/1.36.0-wmf.16] Allow EventGate to default dt to server side receive time

https://gerrit.wikimedia.org/r/641799

Change 641799 abandoned by Ottomata:
[mediawiki/extensions/EventLogging@wmf/1.36.0-wmf.16] Allow EventGate to default dt to server side receive time

Reason:
bad change-id

https://gerrit.wikimedia.org/r/641799

Change 641801 had a related patch set uploaded (by Ottomata; owner: Ottomata):
[mediawiki/extensions/EventLogging@wmf/1.36.0-wmf.16] Allow EventGate to default dt to server side receive time

https://gerrit.wikimedia.org/r/641801

Change 641768 had a related patch set uploaded (by Urbanecm; owner: Ottomata):
[mediawiki/extensions/EventLogging@wmf/1.36.0-wmf.18] Allow EventGate to default dt to server side receive time

https://gerrit.wikimedia.org/r/641768

Change 641801 merged by jenkins-bot:
[mediawiki/extensions/EventLogging@wmf/1.36.0-wmf.16] Allow EventGate to default dt to server side receive time

https://gerrit.wikimedia.org/r/641801

Change 641768 merged by jenkins-bot:
[mediawiki/extensions/EventLogging@wmf/1.36.0-wmf.18] Allow EventGate to default dt to server side receive time

https://gerrit.wikimedia.org/r/641768

Mentioned in SAL (#wikimedia-operations) [2020-11-18T19:45:21Z] <otto@deploy1001> Synchronized php-1.36.0-wmf.18/extensions/EventLogging/modules/ext.eventLogging/core.js: EventLogging legacy events should use dt as server side receive time - T240460 (duration: 01m 07s)

Mentioned in SAL (#wikimedia-operations) [2020-11-18T19:48:46Z] <otto@deploy1001> Synchronized php-1.36.0-wmf.16/extensions/EventLogging/modules/ext.eventLogging/core.js: EventLogging legacy events should use dt as server side receive time - T240460 (duration: 01m 06s)

FYI @nettrom_WMF, I just deployed the change today to make legacy EventLogging events have dt be a server side receive time (this should match exactly meta.dt). They will still have client_dt as the client side timestamp as well.

Also FYI, in the near future in non-legacy schemas in event platform dt will be a client side timestamp, and meta.dt will be server side receive time.

Change 645201 had a related patch set uploaded (by Mholloway; owner: Michael Holloway):
[mediawiki/extensions/EventLogging@master] Update EPC-JS to add 'dt', not 'client_dt', in core.submit

https://gerrit.wikimedia.org/r/645201

Change 646752 had a related patch set uploaded (by Mholloway; owner: Michael Holloway):
[schemas/event/secondary@master] fragment/analytics/common: rename 'client_dt' to 'dt'

https://gerrit.wikimedia.org/r/646752

Change 646753 had a related patch set uploaded (by Mholloway; owner: Michael Holloway):
[schemas/event/secondary@master] Update analytics/mobile_apps/android_user_contribution_screen to require 'dt'

https://gerrit.wikimedia.org/r/646753

Change 646793 had a related patch set uploaded (by Mholloway; owner: Michael Holloway):
[schemas/event/secondary@master] Update analytics/session_tick to require 'dt'

https://gerrit.wikimedia.org/r/646793

Change 646796 had a related patch set uploaded (by Mholloway; owner: Michael Holloway):
[schemas/event/secondary@master] Update analytics/test to require 'dt'

https://gerrit.wikimedia.org/r/646796

Change 646788 had a related patch set uploaded (by Mholloway; owner: Michael Holloway):
[schemas/event/secondary@master] Update analytics/mobile_apps/ios_edit_history_compare to require 'dt'

https://gerrit.wikimedia.org/r/646788

Change 646807 had a related patch set uploaded (by Mholloway; owner: Michael Holloway):
[mediawiki/extensions/WikimediaEvents@master] Update sessionTick.js to produce to session_tick schema v2.0.0

https://gerrit.wikimedia.org/r/646807

Change 646752 merged by Mholloway:
[schemas/event/secondary@master] fragment/analytics/common: rename 'client_dt' to 'dt'

https://gerrit.wikimedia.org/r/646752

Change 646796 merged by Mholloway:
[schemas/event/secondary@master] Update analytics/test to require 'dt'

https://gerrit.wikimedia.org/r/646796

Change 646753 merged by Mholloway:
[schemas/event/secondary@master] Update analytics/mobile_apps/android_user_contribution_screen to require 'dt'

https://gerrit.wikimedia.org/r/646753

Change 646788 merged by Mholloway:
[schemas/event/secondary@master] Update analytics/mobile_apps/ios_edit_history_compare to require 'dt'

https://gerrit.wikimedia.org/r/646788

Change 646793 merged by Mholloway:
[schemas/event/secondary@master] Update analytics/session_tick to require 'dt'

https://gerrit.wikimedia.org/r/646793

Change 645201 merged by jenkins-bot:
[mediawiki/extensions/EventLogging@master] Update EPC-JS to add 'dt', not 'client_dt', in core.submit

https://gerrit.wikimedia.org/r/645201

Change 646807 merged by jenkins-bot:
[mediawiki/extensions/WikimediaEvents@master] Update sessionTick.js to produce to session_tick schema v2.0.0

https://gerrit.wikimedia.org/r/646807