With the move to AWS, Vindicia is also moving the local time zone for both Subscribe and Retain to UTC (from PST).
As a result, all times will now be stored internally as UTC, and all scheduled activities, such as the daily subscription renewal process and Retain retry processing, will be triggered according to UTC timelines. For example, instead of daily subscription renewal processing occurring just after midnight PST, with the move to AWS, that process will now occur just after midnight UTC.
Using UTC as the baseline time zone for operations brings Vindicia inline with industry best practices and more accurately reflects Vindicia's growing global presence.
More importantly, it will enable Vindicia to more readily expand the capabilities of the Vindicia suite of products and to bring new and sought after enhancements to market faster.
Impact of UTC
At Vindicia, we know and understand that the move to UTC may have an impact on our existing customers and we want to ensure you are prepared for the changes to come.
To be clear, this move will not impact your revenue. End-user subscriptions will continue to renew and at the prescribed price point. Campaigns will continue to be applied and payments will continue to be collected etc.
Of course, there may be some changes to your operational environment. The following sections describe the impacts to Subscribe and Retain as a result of the move to UTC and describe how those changes may impact your integration with Vindicia.
Shorter Initial Billing Cycle
The first change you're likely to notice is the first time a subscription renews following the move to AWS. At this time subscriptions will renew earlier than expected, depending on the time zone you are in.
For example, if you are in PST now, you are used to subscriptions renewing just after midnight local time. After the move to AWS, those subscriptions will now renew just after midnight UTC, a full 8 hours earlier. While there is no change on the renewal charge, the renewal will occur 8 hours before expected.
If you are in UTC now, you are used to subscriptions renewing just after 08:00 hours UTC. They will now renew just after midnight UTC, a full 8 hours earlier than expected.
If you are in AEST now, you are used to subscriptions renewing just after 16:00 hours AEST. They will now renew just after 08:00 hours AEST.
Note that this applies only to the first renewal after the move to AWS. The amount of the renewal will not be impacted.
Depending on your current time zone, however, this may mean a given subscription renews a day earlier than expected. That change will be permanent, meaning that if the move to AWS causes a given subscription to renew one day earlier than expected (i.e. renews on the 1st instead of the 2nd), that change will be permanent. Following the move to AWS that subscription will always renew on the 1st UTC time.
Shorter Grace Period/Earlier Cancelation
If the service happens to be in grace, depending on your current time zone, that grace period may be one day shorter than expected.
If the service happens to have been canceled as of the end of the current billing cycle, depending on your current time zone, that last billing cycle may be one day shorter than normal.
Note this only impacts subscriptions that were in grace or in a cancel pending state at the time of the move to AWS.
If you are using Portal 1.0, all times will be displayed in UTC and any fields that include a time component will be in UTC. Any date fields you populate using Portal 1.0, for example when creating a subscription via the portal, will be assumed to be in UTC.
If you are using Portal 2.0, the system will display dates based on your local setting. This means that even though the times are stored as UTC, they will display based on your local settings. The same holds for date fields populated using Portal 2.0, the system will assume the time zone of your local.
Push notifications are triggered by different events in the systems, including subscription renewals. This means that some push notifications will occur shortly after midnight UTC instead of PST.
In addition, currently, the dates in the push notification payload are represented in PST.
After the move to AWS those dates will be represented in UTC.
If you are using the date fields in push notifications to trigger other activities, such as API calls into other systems, or to populate a data warehouse, you'll want to account for the change in time zones from PST to UTC.
If you have not already done so, Vindicia recommends that you adopt Reports 2.0. Reports 2.0 leverages Vindicia's data platform. The data platform operates in UTC and is updated on a daily basis at 13:00 UTC time. This means that, if you operate in UTC, the reports that include records for June 27, will be available on June 28 @ 13:00. If you operate in PST, reports that include records for June 27 up to 16:00 PST will be available on June 28 @ 05:00.
When generating reports using Reports 2.0 you can select the time zone you want to report to display in.
If you have scheduled reports, you will need to update the schedule following the move to AWS to adjust that schedule to the appropriate time zone.
Reports generated using Reports 1.0 will have date fields in UTC.
Subscribe and Retain API
In addition to the above, how Subscribe and Retain interpret and return date field values will also be changing.
For APIs, both Rest and SOAP, dates can be passed in different formats;
- Date & Timestamp with Timezone (2021-01-18T10:30:00-8:00)
- Date & Timestamp with Timezone merchant option is set to ignore timezone (old setting, relevant for very few merchants)
- Date & Timestamp no Timezone (2021-01-18T10:30:00)
- Date Only (2021-01-18)
- No date or time
Currently, for all cases where there was not a specific identification of the time offset, Subscribe/Retain assume the date is in PST.
Following the move to AWS, Subscribe/Retain will assume the date is in UTC.
See API Date Time Examples for more information.
If you are currently including the time zone offset in the date field then Subscribe/Retain will continue to honor that offset and use it to convert the value you passed into UTC.
However, if you are currently passing in a time value BUT are not passing in the corresponding time zone offset, you will need to update your system to include the time zone offset unless you want the system to assume UTC.
Likewise, any time values returned by Subscribe/Retain via the APIs will have a time component in UTC (with proper time zone offset indicated)
If you are currently assuming the time value is in PST, you will need to update your system accordingly.
How to prepare for the move to UTC
While the move of Subscribe and Retain from PST to UTC may impact aspects of your current Vindicia powered solution it is important to note this change will not impact your revenue. End-user subscriptions will continue to renew and at the prescribed price point. Campaigns will continue to be applied and payments will continue to be collected.
That's not to say there will be no impacts, depending on how you have integrated with Vindicia and how you use our solutions, you may need to make some adjustments but those adjustments will not impact your bottom line.
When trying to determine how or if you might be impacted here are a few questions that might help.
- Do you bill users on a specific day of the month? Some subscriptions renew on the anniversary date of the original purchase. In other cases, you may want a subscription to start and/or renew on a specific day of the month. If this is the case, the move to UTC may cause some of your subscribers to renew one date earlier than expected.
- Do you have subscriptions that terminate on a specific day? If so, they may terminate one day earlier than expected.
- Do you have future-dated subscriptions? Sometimes merchants sell subscriptions in advance of their start date, like movie premiers. If this is the case for you, the start date of the subscription may shift by 1 day.
- Do you have subscriptions in a pending cancelation state? If you do those subscriptions may cancel one day earlier than expected
- Do you use push notifications to trigger updates to 3rd party systems such as populating a data warehouse or calling a 3rd party API.
- Do you use the date value returned from a Subscribe or Retain API call to trigger updates to 3rd party systems such as populating a data warehouse or calling a 3rd party API?
- Do you synchronize data between Subscribe and other online systems such as a webstore front, self-care portal, or CSR interface?
- Does Vindicia generate any proprietary reports for you on a scheduled basis? If so, you may want to have Vindicia adjust that schedule for you.
- Within your NOC do you have processes or procedures that are timed to execute based on the Subscribe or Retain processes? If so you may want to adjust the execution time of those processes.
If you have said yes to any of the above, you may be impacted by the move to AWS.
If you feel you may be impacted but are not sure or if you know you are but need more information, we are here to help. Reach out to us at email@example.com, we'd be happy to help assess any impacts you may have, answer your questions or provide any additional information you may need.
Your Vindicia Partner.