compare datetime objects with pytest.approx

[brianmaissy]

I frequently find myself comparing datetime objects with an interval, and thought it would be convenient if approx() supported datetimes.

It would work similarly to numbers, except the absolute tolerance would be a timedelta, and the relative tolerance would be a number which would be interpreted as a fraction of the datetime's distance from the epoch, or something like that. Admittedly a relative tolerance has less of a use for datetimes, so I would make the default 0, and possibly even disable relative tolerances.

It doesn't solve a really critical problem, because subtracting datetimes and comparing against a timedelta isn't the end of the world, nor is converting them both to timestamps and comparing them as numbers with approx(), but I think it would be convenient.

While we are at it, we could also support comparing timedeltas themselves, which is even more straightforward.

I am a little concerned about the slippery slope of trying to support approximate comparison of every type, in which inevitably the semantics of approx() will break down, but in this case datetimes and timedeltas are pretty "number-like", in that they have a clear numerical interpretation, and already support arithmetic operations, absolute value, etc.

I considered implementing it as a plugin, but I think part of the convenience would be that the same approx() function which people already know and love would just work for datetimes.

Let me know if you think this is a good idea, and if so, I'd be happy to implement it.

[RonnyPfannschmidt]

it definitively sounds like a good idea, what i'm on the fence about is whether to give it a new name

from my pov the meanings of absolute and relative epsilon seem to be slightly different on datetime values

i would like to propose fleshing out the meanings first, and from there it will be absolutely clear on whether we will need a new name or if the same name is a great fit

[brianmaissy]

Absolute seems to make sense like this:

a_little_while_ago = datetime.now()
assert a_little_while_ago == pytest.approx(datetime.now())
assert a_little_while_ago == pytest.approx(datetime.now(), abs=timedelta(seconds=1))

Passing a number could also be implicitly understood as number of seconds (because I think people are used to thinking of the numerical representation of a datetime being its timestamp):

a_little_while_ago = datetime.now()
assert a_little_while_ago == pytest.approx(datetime.now(), abs=1)

Indeed I'm not sure what relative should mean, and I can't think of any use case. Datetimes are by nature all of the same order of magnitude. I think relative comparison should be disabled for them.

[brianmaissy]

And for timedeltas, both abs and rel make sense

about_one_day = timedelta(days=1, seconds=1)
assert about_one_day == pytest.approx(timedelta(days=1), rel=timedelta(seconds=1))
# a numerical rel is interpreted as seconds
assert about_one_day == pytest.approx(timedelta(days=1), rel=1)
assert about_one_day == pytest.approx(timedelta(days=1), rel=.001)

[RonnyPfannschmidt]

i believe a key question is how to make sense of things if rel/abs are not given (as the current defaults orient on numeric values, not time values, and im under the impression to make sensible approximations for times its critical to set one or both

[Zac-HD]

I'd make it an error to ask for relative tolerance for datetimes, because it's not really clear what that means.

Defaulting both types to an absolute tolerance of one second seems sensible to me, as a standard small difference.

[brianmaissy]

I agree, one second seems like a reasonable default

[brianmaissy]

I wrote a first-draft implementation, and came across a number of dilemmas. Let's continue discussing the implementation at #4760?

[brianmaissy]

Withdrawing the proposal