Time Precision

[imix]

Hi,

would it be possible to add an option "TimePrecision" analog to "FloatPrecision" which would permit to Truncate the times before comparison.

Reason:
I use deep.Equal to test my Database Interface. I compare the stored Struct with the original one (which contains timestamps). The DB I use (postgres) has a time resolution of Microsecond whereas the golang time.Time has a resolution of Nanosecond. Being able to truncate the timestamps would permit to compare those two.

thanks for considering

[daniel-nichter]

This should be/might be handled by Time.Equal? If the things being compared have an Equal method, it's used:

        // Types with an Equal() method, like time.Time, only if struct field
        // is exported (CanInterface)
        if eqFunc := a.MethodByName("Equal"); eqFunc.IsValid() && eqFunc.CanInterface() {

Are you using time.Time structs?

[imix]

Yes, I'm using time.Time. The only way I currently see is to use an own type with an own Equal method? I wouldn't want to change all time.Time like this as an artifact of testing. Is there a better way?

[daniel-nichter]

Sorry for slow reply. I'm not sure how to handle this. Time.Equal() is authoritative for itself, so I don't think we should mess with that. I'm surprised Go isn't zeroing out the nanosecond part of the time? I.e. I'd expect loading 500ms from db into a time.Time to equal 500000000 nanoseconds. It's not doing this?

[philippgille]

I'd expect loading 500ms from db into a time.Time to equal 500000000 nanoseconds. It's not doing this?

It is. But: From the original message:

The DB I use (postgres) has a time resolution of Microsecond whereas the golang time.Time has a resolution of Nanosecond

So if you create a time.Time object with 1234 nanoseconds, it will be stored as 1 microsecond so the retrieved time.Time object is 1000 nanoseconds. When you compare the two objects it fails of course.

One option is to use Truncate() on the time object when initially creating it, but this might not always be possible if the time's creation is not under your control and you can't change it in the test code, so the OP is asking for a way to tell this comparison library to reduce the precision.

One way that could maybe be done is if your library goes through all the fields by itself and you have access to all objects, you could truncate one or both time objects just before comparing them based on the precision that's configured for the comparison.

[daniel-nichter]

Thanks, I see the issue and I agree: if one wants 1000 ns == 1234 ns to be true, then sure. But I'll have to poke at the code to see if it's possible to do this without too much special-case code.

The workaround, which maybe the OP already does, is to explicitly test/round time values retrieved from the db, then zero out the time values when comparing against all the other expected values. Or, if the input can be controlled, then provide known time values that store and retrieve exactly.