Closed iamkeir closed 1 year ago
Actually, wait, I think cancel_at
is an internal plugin value, whereas endDate
(and canceledAt
) are coming from Stripe. Perhaps Stripe changed the format of these values?
Yep, canceledAt
is also a string.
Currently, we're mapping endDate
-> current_period_end
(from the subscription object) to convert from timestamp (int) to string (human readable)
I will take a look.
Ok, let us know. Timestamp (int) is far more useful as it can be manipulated into any date string users require, whereas the string format is prone to error due to dd/mm/yyyy
vs mm/dd/yyyy
.
We just released Stripe Payments v4.1.0 (Craft3) and v5.1.0(Craft4) with a fix to this issue. If there is an error it will return the date as comes from Stripe
@iamkeir you can access to original stripe's data from: $subscription->data
Sorry I wanted to say $subscription->data
, our subscription
object it's just a human-readable wrapper of Stripe's subscription object, if you need the data as comes from Stripe you can use:
In PHP
$subscription->data['canceled_at'];
or in Twig:
{{ subscription.data.canceled_at }}
{{ subscription.data.current_period_end }}
You will be able to get the dates as timestamps if you need them
Description
We recently updated the Stripe Payments plugin from a very old version and now the subscription
endDate
seems to return astring
instead of aninteger
, unlikecancel_at
which is still an integer (looks like epoch integer).As such, if you have a date string such as "22/12/24",
date('d/m/Y')
fails as it is getting muddled by which part of the string is month and which is day (and 22 is too large for month), and it throws:Is this something that could have changed in some updates? Or maybe on the Stripe side? Ideally it would be an integer as strings are unreliable for this reason.
Additional info