Hey folks, I was helping with some accounting and we noticed the payments data was not being localized with timezone set for the space. This was notably just the data field on api/v1/payments/ via API, which also surfaces on the website as that date is shown upfront for the payments. This was noticed as other related data, like invoices, have a correctly localized date
As a sidenote, I thought it might be possible to take createdAt or updatedAt and localize it to correct for this, but I see it’s a little more complex than that and there’s cases of non-Stripe payments which are way off (data entry?) as well as those which have dates somewhere between createdAt or updatedAt with a wider spread (days to weeks). I assume that there’s just some logic on Fabman’s side or pulling dates that aren’t exposed (e.g. from Stripe).
Hey @legojoey17,
I’m not quite sure if I understand you correctly. The API always returns all dates in ISO format (not localized), including for payments and invoices.
But both the admin site and the member site should show all dates in localized form. Can you point me to where you saw a non-localized payment date on the website?
Yep, to give you a specific example take a look at https://fabman.io/api/v1/payments/23952.
You’ll see that payment, as well as the associated invoice, has a "createdAt: "2024-06-01T02:xx". The invoice (https://fabman.io/api/v1/invoices/77622) has date: "2024-05-31" which is what we expect to also be present on the payment, but the payment has date: "2024-06-01". Similarly, the website UI also has the same error when showing the payment page (https://fabman.io/manage/2189/billing/23952) as well as the invoice page which references the payment and its date (https://fabman.io/manage/2189/billing/invoices/77622).
Cross-referencing on the Stripe dasboard we can see the charge was attempted immediately succeeded and is localized and shown as 2024-05-31 19:xx which is expected given our space’s timezone is -7:00 / Pacific Time, set in both Fabman and Stripe.
I sort of figured you might be localizing date on the API for the website, while createdAt and updatedAt are ISO format, but I might be jumping to conclusions on that (:
1 Like
Thank you for the clarification!
The problem was that creating payments via the payment intent API (i.e. all Stripe payments) set the payment date to the server’s day, not the space’s. (Non-Stripe payments were not affected.)
We just rolled out an update that fixes this problem for all new payments.
Thank you for reporting this!