Proper setting of originTime on subscriptionBillingAttemptCreate

Retired Boards Appdev Subscriptions
1

I’m confused about the 2022-04 API new field originTime on subscriptionBillingAttemptCreate.

This field is definitely required for proper behavior of subscription orders/fulfillments when anchors are present. The docs seem to indicate that the value should be passed with the shop time zone as the UTC offset. However, in my testing to get the desired behavior I need to coerce the shop-local date back into UTC without actually changing the date/time (i.e., truncate/replace the time zone).

Here is an example:

  • Shop location: Sydney, Australia

  • Shop UTC offset: +10:00

  • Current UTC time: 2022-04-20T15:00:00Z (Wednesday)

  • Current shop time: 2022-04-21T01:00:00+10:00 (Thursday)

  • Contract existing with anchor for every Wednesday

  • Contract is ready to bill at the current time

In attempt A we send the following:

  • originTime: 2022-04-21T01:00:00+10:00 (including the UTC offset)

In attempt B we send the following:

  • originTime: 2022-04-21T01:00:00Z (using the local date/time but effectively dropping the offset)

Note that in both cases it is effectively Thursday in the shop’s local time zone. And, further, the actual date/time is Thursday in the shop’s time zone. That is, “right now” is Thursday in Australia.

But, attempt A results in an order that has an open fulfillment (unexpected behavior) while attempt B results in an order that has a scheduled fulfillment (expected behavior).

What am I missing?

2

Hey @CakewalkRussell

Are you able to post some more details or DM me about how your contract is setup? Anchors, Pre Anchor Behaviour, etc.

For scenario A 2022-04-21T01:00:00+10:00 that is 1 am shop local time.

For scenario B 2022-04-21T01:00:00Z that is 11 am shop local time.

The big difference here is that they cross midnight UTC. I would love to test this with the same contract setup you have to verify this issue.

Thanks!

3

Yes, sure. The contract that I’ve been testing with has pre-anchor behavior of ASAP, a 1 week billing/delivery recurrence and an anchor type weekday + only Wednesday (day=3). To test above I’ve just been manually updating the nextBillingDate to the current time in GraphQL and issuing the billing attempt create mutation with variations of originTime as noted above (and other variations). I’m happy to post any other details here.

4

@matart We’d still love some guidance here if you end up having a chance to check this out in more detail. If you need any more information about the contract, settings, etc. please let me know. Thanks!

1 Like