Hello, could anybody please take a look into this issue? https://github.com/pact-foundation/pact-jvm/issues/1797 Long story short, i want to not hardcode datetime formats, since we are serializing Instant. and instant can have formats like these

"yyyy-MM-dd'T'HH:mm:ssZ"
"yyyy-MM-dd'T'HH:mm:ss.SSZ"
"yyyy-MM-dd'T'HH:mm:ss.SSSZ"
...
"yyyy-MM-dd'T'HH:mm:ss.SSSSSSSSSZ"

I have tried these so far:

return new PactDslJsonBody()
        .object("Data", looksLike()
                .uuid("ConsentId")
                .datetime("CreationDateTime", INSTANT_ISO_DATETIME_FORMAT, Instant.now())

// "yyyy-MM-dd'T'HH:mm:ss[.[SSSSSSSSS][SSSSSSSS][SSSSSSS][SSSSSS][SSSSS][SSSS][SSS][SS][S]]'Z'";
// static final String INSTANT_ISO_DATETIME_FORMAT = "yyyy-MM-dd'T'HH:mm:ss.SSSSSSSSSZ";
// static final String INSTANT_ISO_DATETIME_FORMAT = "yyyy-MM-dd'T'HH:mm:ss[.SSSSSSSSS]Z";
static final String INSTANT_ISO_DATETIME_FORMAT = "yyyy-MM-dd'T'HH:mm:ss(.SSSSSSSSS)?Z";

Pact doesn't generally have support for using optionals, and we don't recommend doing it.

Thank you for answering @rholshausen! Why is that the recommendation? If i were to say that my consumer expects timestamps in format "yyyy-MM-dd'T'HHmmss.SSSZ", this would not present the real picture of Java's default serialization. This basically leads to incorrect data - consumers would assume that they will always get three digits after seconds, but that would not be the case in reality (if we are using default serializer). Sure, you can configure producer to provide data that fits into the expectation, but in real case you would be providing all other types of timestamp - no millis, with millis, with nanos etc So it seems that pact should either provide a way to support default implementation of serialization, or give instructions on how to approach it?

There is an explanation on why Pact does not support optional values on the docs site https://docs.pact.io/faq#why-is-there-no-support-for-specifying-optional-attributes, this is similar to that.

there is also mention of loose matching in the docs. So i was hoping to make timestamps loosely matched, covering all valid options. However, if we were to provide a different valid value in a provider for some reason, e.g.

2020-01-02T14:40:01.123456789Z

instead of

2020-01-02T14:40:01.123Z

, this would break the test, even though it is a valid value and the consumer would still be getting both options of the value in production. From your suggestions, it seems that the recommendation is to create 4 tests instead of 1 - each testing a possible variant of the timestamp? 🙂 However, i do understand that timestamps are hard and if this is a limitation we need to work with, i guess it is not crucial and there are some regex workarounds. Thank you for taking time to take a look into this!