I didn't see any tests for this module, happy to add one, it's a bit hard to verify with testdrive since it just does string comparison.

I would think that testdrive attempting to parse the timestamptz output format would break?

Hmm, dates-times.td already has a bunch of tests that don't break. I wonder what's going wrong.

Oh, right, because testdrive uses the binary format, which isn't broken. Something like this should do the trick:

diff --git a/test/testdrive/dates-times.td b/test/testdrive/dates-times.td
index 4f802280..92af95c3 100644
--- a/test/testdrive/dates-times.td
+++ b/test/testdrive/dates-times.td
@@ -105,3 +105,6 @@ $ kafka-ingest format=avro topic=data schema=${schema} timestamp=10
 
 > SELECT TIMESTAMPTZ '1989-06-01 9:10:10.410+700'
 "1989-06-01 02:10:10.410 UTC"
+
+> SELECT '1989-06-01 10:10:10.410+04:00'::timestamptz::text
+"1989-06-01 06:10:10.410+00"

Does it parse, or just verify that they match? I'll dig in.

To be clear, I posted my comment about adding tests concurrently with you asking for tests, I'm happy to look into it.

Oh that's a different category of test than I was thinking of, but yeah, that would catch this, I'll add it.

Yeah, sorry, GH reviews is failing to keep up with us :D. The problem is that we don't have any tests of the timestamptz->text cast. Testdrive (or SLT) can handle that if you just force the timestamptz->text cast to happen explicitly in the query, rather than implicitly as part of the pgwire format (since testdrive uses the binary serialization, and SLT looks at Datums directly).

Yeah I was thinking of adding a unit test directly in the module to make sure that it round-trips correctly, but this seems fine to prevent regressions.

Yeah if you do wanna add a unit test heads up that they are in https://github.com/MaterializeInc/materialize/blob/main/src/repr/tests/strconv.rs for this module (i.e., what Cargo would fall an “integration” test). This looks great though!