Time Precision #22

Activity

1. daniel-nichter commented on Nov 18, 2018

   

   daniel-nichter

   on Nov 18, 2018

   Last edited by daniel-nichter

   Member

   More actions

   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?
2. imix commented on Nov 20, 2018

   

   imix

   on Nov 20, 2018

   Author

   More actions

   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?
3. daniel-nichter commented on Jul 14, 2019

   

   daniel-nichter

   on Jul 14, 2019

   Member

   More actions

   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?
4. philippgille commented on May 27, 2020

   

   philippgille

   on May 27, 2020

   More actions

   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.
5. daniel-nichter commented on May 30, 2020

   

   daniel-nichter

   on May 30, 2020

   Member

   More actions

   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.