Holger Brunn
Holger Brunn
you cannot handle this with settings alone. The code as it is normalized every date to UTC, so without changing the code this won't change. What I propose here is...
the force localization is only for the migration script. There, we'll have something like 2021-09-19 00:00:00, and in order to produce the same intervals as before with the code I...
the short description is: Statements contain the UTC interval, not the localized interval if provider.tz is set
what we request from paypal when the statement says '2021-09-19' with CEST is actually the transactions from '2021-09-19 02:00:00 CEST' to '2021-09-20 02:00:00 CEST' (edit: applied the correction the wrong...
I'd expect the statement for the 19th to contain the transactions from '2021-09-19 00:00:00 CEST' through '2021-09-20 00:00:00 CEST', with the matching balance. That's how my customer came to this...
as a user you don't have control which intervals are requested exactly, this complicates things. How can you as a user now set the exact interval? It's part of the...
> > How can you as a user now set the exact interval? > > Please describe in details _why_ anyone would want that? Apart for occasional manual pull described...
yes, it's in production since last year
I'd start by declaring some base class deriving from ValueError (or some other standard exception), and simply add a constructor that allows you to pass whatever data you need to...
PS: Don't forget to override `__str__` to print something sensible using those values