Apps Running SDKs Below Version 5.1
If your app is using a version of the Localytics SDK below version 5.1, the beginning or end of Daylight Savings Time can cause messages using timezone-based delivery to be sent earlier or later than you intend them to be sent. Before SDK 5.1, a user’s timezone is recorded as the number of hours before or after UTC (for example, UTC -5). This offset is updated whenever the user opens your app.
When Daylight Savings begins or ends, the offset changes. For example, at the start of Daylight Savings Time, the Eastern Timezone goes from being UTC -5 to being UTC -4. As a result, after the start or end of Daylight Savings, we will not have accurate timezone information for your users in regions that observe Daylight Savings until they open your app. Users in regions that don’t observe Daylight Savings will be unaffected.
This can result in some odd behavior for campaigns that are using timezone-based delivery:
- In the spring, users who haven’t launched your app since Daylight Savings started will receive your message one hour later than you intended.
- In the fall, users who haven’t launched your app since Daylight Savings ended will receive your message one hour earlier than intended. If you have switched the starting timezone from the default of the international dateline to a timezone that is undergoing the change in Daylight Savings, users in that starting timezone who haven’t opened the app since the end of Daylight Savings will receive the message 23 hours later than intended.
If you are sending a message in the week after a change to Daylight Savings and the message must be received at a specific time, we recommend you modify your campaign’s Audience to only target users who have opened your app since the change. Then duplicate the campaign, adjust the Audience to only target users who haven’t opened the app since the change, and change the scheduling as follows:
- In the spring: Schedule the message to send one hour earlier than you normally would
- In the fall: Schedule the message to send one hour later than you normally would and make sure you leave the starting timezone on the international dateline. Changing the starting timezone will result in users who haven’t opened the app since the end of Daylight Savings receiving the message 23 hours later than intended.
To target users who have launched the app after the change in daylight savings, add the following Profile criteria to your Audience: “Last Session Date” > “is on or after” > (pick the date on which the change in Daylight Savings occurs) > “(date)”
To target users who have not launched the app since the change in daylight savings, add the following Profile criteria to your Audience: “Last Session Date” > “is on or before” > (pick the day before the date on which the change in Daylight Savings occurs) > “(date)”
Apps Running SDKs Above Version 5.1
Beginning with Version 5.1 of the Localytics SDK, we record a user's timezone using the actual timezone name (e.g. "America/Los_Angeles"), instead of a UTC offset. On our end, we track when changes to Daylight Savings occur and automatically update our systems to reflect the change in time. This ensures that users will receive all messages at the intended time, without requiring the user to open the app. As a result, there’s no need to make any adjustments to a message's send time in order to compensate for Daylight Savings if your app is running SDK Version 5.1+.
If you have recently upgraded your app to SDK 5.1+, there’s a good chance that many of your users haven’t updated the app on their device yet. These users will still encounter the issues afflicting older versions of the SDK. If you are sending a message in the week after a change to Daylight Savings and the message must be received at a specific time, we recommend you modify your campaign’s Audience to only target users who have used a version of your app that uses the Localytics SDK version 5.1+. Then duplicate the campaign, adjust the Audience to target users who haven’t used a version of your app with Localytics SDK 5.1+, then follow the targeting and scheduling instructions provided above for apps running older versions of the SDK.
To target users of your app running SDK 5.1+, add the following Profile criteria to your Audience: “Last SDK Version” > “is one of” > (pick all versions listed with numbers greater than 5.1.0)
To target users of your app running an SDK below 5.1, add the following Profile criteria to your Audience: “Last SDK Version” > “is none of” > (pick all versions listed with numbers greater than 5.1.0)
Keep in mind that although the new approach used starting in SDK 5.1 automatically compensates for Daylight Savings, if the user physically moves to a location in a different timezone, they still need to open the app in order for Localytics to learn that the user’s timezone has changed.