String-ified timestamps are generated in two different ways in the library:
sepaxml.utils.make_msg_id relies on the time module to generate the timestamp part of the message ID
sepaxml.debit._create_header and sepaxml.transfer._create_header rely on the datetime module for a similar feature (the timestamp in the message header)
The problem caused by 1) is that popular (date-)time mocking methods (e.g. mocking the datetime module, or using freezegun) do not work for both at once.
Use-case: I want to have a reproducible XML export in my test suite.
I thought everything was working fine with freezegun but the CI/CD pipeline highlighted the flakiness of my mock.
datetime is mocked alright, but time still relies on the machine local timezone offset, not on the mocked value.
I will open a PR with my very naive solution: using datetime in sepaxml.utils.make_msg_id to generate the timestamp.
String-ified timestamps are generated in two different ways in the library:
sepaxml.utils.make_msg_id
relies on thetime
module to generate the timestamp part of the message IDsepaxml.debit._create_header
andsepaxml.transfer._create_header
rely on thedatetime
module for a similar feature (the timestamp in the message header)The problem caused by 1) is that popular (date-)time mocking methods (e.g. mocking the
datetime
module, or usingfreezegun
) do not work for both at once.Use-case: I want to have a reproducible XML export in my test suite. I thought everything was working fine with
freezegun
but the CI/CD pipeline highlighted the flakiness of my mock.datetime
is mocked alright, buttime
still relies on the machine local timezone offset, not on the mocked value.I will open a PR with my very naive solution: using
datetime
insepaxml.utils.make_msg_id
to generate the timestamp.