Design question: Time-dependent behavior in get_window()

[AnujNayak108]

Hi, I was exploring quartz-api and noticed that get_window() in utils.py
relies on datetime.now() internally to compute the time window.

Wouldn't this make the function time-dependent and harder to test
deterministically? Would it be preferable to pass a reference time
explicitly (using now() only at the API boundary)?

[braddf]

Hey @AnujNayak108, great to have you, and good point here. There are definitely a bunch of things like this across our active repos that we'll be looking to hunker down in the new year and weed out the... less ideal patterns, and untestable elements. 😁

Your suggestion makes total sense, and seems fairly self-contained as an implementation change as I see it (though I haven't looked for all the usages of the function), so by all means pop a PR up with an amended function that splits the logic out in this way with a new (default) now() parameter if you'd like!
I agree, this would be much easier to reason with firm test cases, and presume this was added in at some point to solve an immediate problem, and we haven't had the need to update this since – it's a fairly set default time window, but we might need to change/set this differently in the future.

Any questions though, on this or other repos, give us a shout!

GL;HF 👍

[AnujNayak108]

Thanks a lot for the detailed reply and glad the
approach sounds reasonable.

I’ll take a look at all the usages of the function and open a PR that
splits out the logic with an explicit reference time (keeping now()
as the default), along with some tests to make the behaviour clearer
and deterministic.

I’ll contact you if I have any questions along the way , thanks again 😄!