[GH-ISSUE #500] Created-Timestamp should always have a constant number of digits for nanoseconds #325

New issue

Closed

opened 2026-03-15 13:53:42 +03:00 by kerem · 4 comments

kerem commented

2026-03-15 13:53:42 +03:00

Owner

Originally created by @siom79 on GitHub (May 23, 2025).
Original GitHub issue: https://github.com/axllent/mailpit/issues/500

When looking at the Created field in the /api/v1/messages API, I see different numbers of digits for nanoseconds:

...
"Created":"2025-05-23T13:31:12.24Z"
...
"Created": "2025-05-23T13:10:57.604Z",
...

The different number of nanoseconds digits causes problems when parsing it for example in Java:

ZonedDateTime.parse(created, DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss.SSSz"));

The above will cause an java.time.format.DateTimeParseException: Text '2025-05-23T13:31:12.24Z' could not be parsed at index 20.

Is it possible to always return a constant number of digits?

Originally created by @siom79 on GitHub (May 23, 2025). Original GitHub issue: https://github.com/axllent/mailpit/issues/500 When looking at the `Created` field in the `/api/v1/messages` API, I see different numbers of digits for nanoseconds: ``` ... "Created":"2025-05-23T13:31:12.24Z" ... "Created": "2025-05-23T13:10:57.604Z", ... ``` The different number of nanoseconds digits causes problems when parsing it for example in Java: ```java ZonedDateTime.parse(created, DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss.SSSz")); ``` The above will cause an `java.time.format.DateTimeParseException: Text '2025-05-23T13:31:12.24Z' could not be parsed at index 20`. Is it possible to always return a constant number of digits?

kerem closed this issue

2026-03-15 13:53:47 +03:00

kerem commented

2026-03-15 13:53:53 +03:00

Author

Owner

@axllent commented on GitHub (May 23, 2025):

Hi @siom79. I see your struggle. The "issue" here is that Go's default RFC3339 format includes the fraction of seconds (which Mailpit uses as it can receive hundreds of emails per second). Fractions are however always "trimmed" when they contain trailing zeros. Given that Mailpit stores the messages using UnixMilli, there will only ever be a maximum of 3 decimals, however there can be 2 (as you've seen), 1, or even none at all. I'm not even sure 2025-05-23T13:10:57.600Z is technically valid RFC3339.

Rather than try work around the standard RFC3339 (internet time) format which is being used here, have you tried something like this: "yyyy-MM-dd'T'HH:mm:ss[.SSS]z"? I have absolutely not idea if that works, but if so then you can thank ChatGPT...

@axllent commented on GitHub (May 23, 2025): Hi @siom79. I see your struggle. The "issue" here is that Go's default RFC3339 format includes the fraction of seconds (which Mailpit uses as it can receive hundreds of emails per second). Fractions are however always "trimmed" when they contain trailing zeros. Given that Mailpit stores the messages using UnixMilli, there will only ever be a **maximum** of 3 decimals, however there can be 2 (as you've seen), 1, or even none at all. I'm not even sure `2025-05-23T13:10:57.600Z` is technically valid RFC3339. Rather than try work around the standard RFC3339 (internet time) format which is being used here, have you tried something like this: `"yyyy-MM-dd'T'HH:mm:ss[.SSS]z"`? I have absolutely not idea if that works, but if so then you can thank ChatGPT...

kerem commented

2026-03-15 13:53:58 +03:00

Author

Owner

@siom79 commented on GitHub (May 24, 2025):

Hi, @axllent,
the RFC3339 declares indeed in section 5 that the number of digits is flexible:

time-secfrac    = "." 1*DIGIT

As far as I understand this ABNF notation, it means that DIGIT must appear at least once (see here):

1*< element > requires at least one

So you are right with mailpit and I close this issue. Thanks for your fast feedback.

@siom79 commented on GitHub (May 24, 2025): Hi, @axllent, the RFC3339 declares indeed in [section 5](https://www.rfc-editor.org/rfc/rfc3339#section-5) that the number of digits is flexible: ``` time-secfrac = "." 1*DIGIT ``` As far as I understand this ABNF notation, it means that DIGIT must appear at least once (see [here](https://www.rfc-editor.org/rfc/rfc2234#section-3.6)): > 1*< element > requires at least one So you are right with mailpit and I close this issue. Thanks for your fast feedback.

kerem commented

2026-03-15 13:54:03 +03:00

Author

Owner

@axllent commented on GitHub (May 24, 2025):

Super. It would still be very helpful to others however if you can confirm the syntax I suggested works, thanks.

@axllent commented on GitHub (May 24, 2025): Super. It would still be very helpful to others however if you can confirm the syntax I suggested works, thanks.

kerem commented

2026-03-15 13:54:08 +03:00

Author

Owner

@siom79 commented on GitHub (May 24, 2025):

Unfortunately the square brackets did not work as expected. The following worked:

ZonedTimeDate.parse("2025-05-23T13:10:57.6Z");

@siom79 commented on GitHub (May 24, 2025): Unfortunately the square brackets did not work as expected. The following worked: ```java ZonedTimeDate.parse("2025-05-23T13:10:57.6Z"); ```