#teeluxiii-testClock-invoiceList
1 messages · Page 1 of 1 (latest)
Hello! We'll be with you shortly. Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- teeluxiii, 6 days ago, 4 messages
Hi 👋
I'm pretty sure this is a known feature of the List API
That is because the actual created time will always be the timestamp of when the record was created. But when there is a test clock associated then some parts of the API read the Test Clock frozen_time property instead
Okay that explains it, the API is masking the true created with the frozen_time
is that documented anywhere?
any reason why listing doesn't adhere to the test clock time?
It looks like this is a known issue. I have added a comment that you have experienced it as well
okay appreciate that! not an issue in production but still, hard to test certain scenarios when listing any historic data based on the current day/frozen_time
Yes that makes sense. I think it would be actually simpler for the APIs if they had an optional frozen_time parameter
Anything to be able to query the data correctly haha
Right, and I think having the frozen_time parameter would be a more correct query. Since it retains the truth of when the object was created while allowing you to query on what the simulated time is
I guess the frozen_time is not included in the public objects but is maintained at the time of the object creation for that masking
If you wish to be kept updated of any changes to the APIs related to Test Clocks you can write in to Support https://support.stripe.com/contact and mention my screen name (Snufkin). I can't promise anything will happen any time soon but it will ensure you get notified if something about this changes