Tests fail in Drone CI due to Go & Postgres `wall` mismatch in `time.Time` values

Question

The problem

I'm running some database query tests with testify.
The tests run in Drone CI by connecting to a postgres container running as a service.
I consistently get test failures (only in CI, the tests pass when running locally with dockertest on a macOS system) when comparing expected & actual values for the created_at and updated_at columns. Both of these columns are TIMESTAMPTZ.
It seems the wall values are different between the two, maybe due to Postgres being limited to microsecond precision whereas Go is limited to nanosecond. Please correct me if this is wrong.
What I've seen is the expected value look like 630636934 and the actual value look like 630636000, for example:

Diff:
--- Expected
+++ Actual
@@ -3,3 +3,3 @@
CreatedAt: (*time.Time)({
-   wall: (uint64) 630636934,
+   wall: (uint64) 630636000,
ext: (int64) 63845794086,
@@ -33,3 +33,3 @@
UpdatedAt: (*time.Time)({
-   wall: (uint64) 630636934,
+   wall: (uint64) 630636000,
ext: (int64) 63845794086,

I am using GORM with the pgx driver.

Why am I seeing this error only in Drone CI and not locally? In both cases, postgres runs in its own container, though in CI the tests run in a golang image and locally they run on a macOS system.

What I've tried

I've tried creating the database records using time.Now().Truncate(time.Microsecond).Round(0), rather than letting postgres's DEFAULT now() run for those two columns, but was still seeing failures when comparing the expected & actual wall. I was calling .Round(0) in particular because, according to the godocs, that is how you can strip the monotonic clock reading, but this must not work as I expect since the wall values were still present.

I don't understand how I create & store a monotonic-free (supposedly) timestamp, but when it gets retrieved by GORM and compared with the original timestamp, the original wall has precision to the last 3 digits, and the actual wall always seems "rounded down".

To get the tests passing in CI, I ended up using testify's assert.ObjectsExportedFieldsAreEqual(...), but I'd like to better understand why wall differs between expected and actual and only in CI. Again, I'm not seeing these errors when running the tests locally. Also, what are the proper terms to talk about the "precision" of this wall value?

Thanks for any help!

EDIT: To be clear, the question is: Why are the wall values between expected and actual timestamps not matching in Drone CI, but they match locally, and is there a way to have them match in CI?

EDIT2: This is my first SO question. I tried to include as much information as I have as well as what I've tried. Any tips on how to improve the question are appreciated.