Timezones in Analytics

The timezone of the workspace must be taken into account when creating analyses that use:

• Occurrence times (timestamps) of events
• Profile attributes and event parameters (other than occurrence times)

Event occurrence times

In the Synerise database, all events are stored with their times calculated into UTC, regardless of how the event was originally sent to Synerise. For example, if you send an event over the API with the date set to 2022-10-21T05:03:46+02:00, the database saves it as 1666321426000 (Unix Epoch timestamp).

The Analytics module does not consider the original timezone of events - the results are always shown in context of the timezone selected in the settings of the workspace.

Example: event times in different time zones

1. An event is sent with the date May 23, 23:00 in the PST timezone (UTC-8).
2. Its time is saved in the database as 1653375600000. In terms of UTC, this is May 24, 7:00.
3. The event is viewed in a workspace whose timezone is CEST (UTC+2). The event’s time in this view is May 24, 9:00.

Example: event times in different time zones in context of an analysis

1. An event is sent with the date May 23, 23:00 in the PST timezone (UTC-8).
2. The workspace is set to the CEST timezone (UTC+2).
3. A metric which counts all events from May 23 (00:00-23:59 CEST) is created.
4. From the point of view of the workspace’s timezone (UTC+2), the event from step 1 occurred on May 24 at 9:00.
5. The event from Step 1 isn’t included in the metric’s result.

Example: change in workspace time zone settings

2. The workspace is set to the CEST timezone (UTC+2).
3. You create a metric to count events which occurred between 14:00 and 17:00 (12:00-15:00 UTC).
4. The settings of the workspace are changed and the timezone is now PST (UTC-8).
5. You open the same metric.
6. The metric result is different than before.

This is expected behavior. In the new timezone of the workspace, the date range of the metric is now 14:00-17:00 PST, which calculates into 22:00-01:00 UTC.

Example: Daylight Saving Time change

This example is similar to the previous one, but the timezone in the workspace changes due to DST, not a change in the geographical timezone settings.

1. The workspace is set to the CEST timezone (UTC+2).
2. A trend is created on October 15. The trend shows events which occurred on October 10, in hourly intervals.
3. You open the trend and see that the most events occurred at 14:00.
4. On October 30, the DST changes. The workspace’s timezone is now CEST (UTC+1).
5. You open the same trend on November 3 to view its results.
6. The trend shows that the most events occurred at 13:00.

This is expected behavior. The results are always shown according to the current timezone of the workspace. If the timezone’s DST status changed since it was last viewed, the analysis results are shown in context of the new DST status.

Example: relative date filter with Daylight Saving Time change

1. The workspace is set to the CEST timezone (UTC+2).
2. A trend is created on October 15. It shows events from the last 30 days, in daily intervals.
   The 30-day period is set as relative to the time of viewing the trend.
3. You open the trend and see that 1500 events occurred on October 14.
4. On October 30, the DST changes. The workspace’s timezone is now CEST (UTC+1).
5. You open the same trend on November 3 to view its results.
6. The trend shows that the number of events on October 14 is different than before.

This is expected behavior. The results are shown according to the current timezone of the workspace. For example:

• When an event occurred on October 14 at 00:30, it was in the UTC+2 timezone.
• When you open the same analysis after changing to UTC+1, it is interpreted as 23:30 on October 13.

Profile attributes and event parameters

In the free-form additional data (attributes in profiles and params in events), you can send other dates/times as custom parameters, as required by your integration.

Example attribute in a profile:

{
    "clientId": 6855607997,
    "email": "default_unique_71fa217a-4c72-4224-89d0-780b7fdfda16@anonymous.invalid",
    ...
    "agreements": {
        ...
    },
    "attributes": {
        "exampleCustomAttribute": "2023-08-03T11:30:00",
    },
    "tags": []
}

{
    "time": "2023-08-04T14:08:33.990Z",
    "action": "docs.read",
    "client": {
        "id": 6855607997,
        "email": "default_unique_71fa217a-4c72-4224-89d0-780b7fdfda16@anonymous.invalid",
        "uuid": "eb73d1c7-c9de-491a-a7bf-992a7167311c"
    },
    "params": {
        "exampleCustomParam": "2023-08-03T11:30:00"
    }
}

If you want to use that data in analytics, we highly recommend to send it in the ISO 8601 format. Thanks to this, you don’t need to transform them into another format before running an analysis.

The ISO 8601 format lets you declare the timezone of the date/time you send:

• 2023-08-03T11:30:00 - this date/time doesn’t have a time zone. When using an attribute/parameter with this value in an analysis, it’s considered to be in the timezone of the workspace where you’re creating the analysis.
• 2023-08-03T11:30:00+02:00 - this date/time is in the UTC +02:00 timezone. The workspace’s timezone doesn’t affect it.
• 2023-08-03T11:30:00Z - this date/time is in the UTC timezone (denoted by the Z suffix). The workspace’s timezone doesn’t affect it.