Default MailDateFormat pattern might not be compatible with RFC 2822?

[bohwaz]

mail-api/api/src/main/java/jakarta/mail/internet/MailDateFormat.java

Line 127 in d93e2fd

private static final String PATTERN = "EEE, d MMM yyyy HH:mm:ss Z (z)";

I think the (z) part is incorrect and should be removed according to RFC 2822.

Currently this generates Date headers like this one:

Date: Sun, 7 Dec 2025 15:58:53 +0100 (GMT+01:00)

But the last part between parenthesis is not part of the RFC, and parsing it with some software will fail (for example with PHP) as it specifies two timezones.

[jbescos]

I am trying to find context about when this was set, and it seems it was done in a Mercurial repository, so I cannot investigate about any reason to have that (z).

commit c8c1e6f18b77d3ce2873b0d3bf57b2ef74f27304
Author: shannon@datsun <shannon@datsun> 2007-11-13 00:53:07
Committer: shannon@datsun <shannon@datsun> 2007-11-13 00:53:07
Child: bc04188eed20949f3be6bbbf32e0305cd1499844 (First attempt at reorganizing workspace to follow maven2 conventions. Full build of release using ant. Build mbox release using ant. Still to be done: build with maven2.)
Branches: 1.6.1.x, master, javaee/1.6.1.x, javaee/HEAD, javaee/master, origin/1.6.1.x, origin/issue166, origin/master, origin/securitySMTPissue
Tags: JAVAMAIL-1_4_1

Initial Mercurial repository based on JavaMail 1.4.1 FCS sources.

In https://www.rfc-editor.org/rfc/rfc2822.html?utm_source=chatgpt.com#section-3.3 it talks about the:

zone = (( "+" / "-" ) 4DIGIT) / obs-zone

That we are addressing with Z.

It does not say anything about the zone names, that we are addressing with (z), so we should remove it.

[jbescos]

I am checking the class MailDateFormat and it already has a method to support other 'older' pattern for serialization purposes:

mail-api/api/src/main/java/jakarta/mail/internet/MailDateFormat.java

Line 152 in d93e2fd

fmt.superApplyPattern("EEE, d MMM yyyy HH:mm:ss 'XXXXX' (z)");

I am confused about how to proceed here. Should we change private static final String PATTERN = "EEE, d MMM yyyy HH:mm:ss Z (z)"; by private static final String PATTERN = "EEE, d MMM yyyy HH:mm:ss Z"; and update writeReplace method to use the 'new older' pattern "EEE, d MMM yyyy HH:mm:ss Z (z)" ?.

@jmehrens maybe you have memories about this, do you have any suggestion?.

[jmehrens]

@jbescos I believe @anthonyvdotbe created the changes in

javaee/javamail@c9b1768

He might have some insights on this.

The code that existed prior to this was custom date format which is also present in the history.

[anthonyvdotbe]

The pattern with the double time zone has been there since the original Mercurial commit in 2007.
I don't remember having had discussions about the double time zone at the time.

I'd say changing the formatting is not an option, as there's surely clients of the API that depend on the double timezone being there.
And for parsers, I'd argue they should either only parse what they need (and stop as soon as they've parsed a valid RFC 2822 date-time, as MailDateFormat does) or use a custom pattern to append the double time zone.

[jmehrens]

@jbescos I think we should dig up source for javamail 1.5.6. If I recall correctly MailDateFormat extended Format instead of SimpleDateFormat. I know i have offline backups i can dig through.

[jbescos]

Do we still have the mercurial repository to check the history?.

In any case, from what @anthonyvdotbe said, this could break code of existing users. Do we need a major version do address this?.

[anthonyvdotbe]

Do we still have the mercurial repository to check the history?.

The history of the Mercurial repository was retained when switching to Git, so it's in https://github.com/javaee/javamail/

In any case, from what @anthonyvdotbe said, this could break code of existing users. Do we need a major version do address this?

On the one hand, JavaMail has existed for over 25 years. DateFormat is effectively obsolete since the introduction of java.time.format.DateTimeFormatter in Java SE 8 (which itself is over 10 years old). And there's a DateTimeFormatter.RFC_1123_DATE_TIME constant that obsoletes MailDateFormat.

On the other hand, just now someone requests MailDateFormat's formatting of dates to be aligned with the standard, so that non-Java clients are able to parse them.

I believe the right way forward is to simply clarify the current behavior in the Javadoc and point to DateTimeFormatter.RFC_1123_DATE_TIME. The costs of breaking existing clients just don't outweigh the benefits.

[jbescos]

The commit I wrote before comes already from the javaee repository. It looks that was the first commit.

I am linking other issue here related to the MailDateFormat. Maybe we can address both: #590