Is it save to rewrite unsupported timezone UT to UTC?

I try to parse Date-Headers in eMails.

Sometimes eMails have this Date-Header:

Mon, 18 Jul 2011 05:05:53 UT

Looks like the format described in the javadoc

So I wrote a test for this:

public void testParser() throws ParseException {
    SimpleDateFormat FULL_FORMAT = new SimpleDateFormat("EEE, d MMM yyyy HH:mm:ss Z", Locale.ENGLISH);
    try {
        String baddate = "Mon, 18 Jul 2011 05:05:53 UT";
        System.out.println("NOW: " + FULL_FORMAT.format(new Date()));
        System.out.println("THEN: " + FULL_FORMAT.parse(baddate + "C"));
        System.out.println("---");
        System.out.println(FULL_FORMAT.parse(baddate));
    } catch (Exception e) {
        e.printStackTrace(System.out);
    }
    System.out.println("UTC: " + TimeZone.getTimeZone("UTC"));
    System.out.println("UT: " + TimeZone.getTimeZone("UT"));
}

And this is the output:

[INFO] Running de.e_nexus.web.rm.mail.TestDateParser
NOW: Thu, 29 Feb 2024 11:50:52 +0100
THEN: Mon Jul 18 07:05:53 CEST 2011
---
java.text.ParseException: Unparseable date: "Mon, 18 Jul 2011 05:05:53 UT"
    at java.base/java.text.DateFormat.parse(DateFormat.java:399)
    at de.e_nexus.web.rm.mail/de.e_nexus.web.rm.mail.TestDateParser.testParser(TestDateParser.java:17)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.base/java.lang.reflect.Method.invoke(Method.java:568)
    at org.apache.maven.surefire.junit.PojoTestSetExecutor.executeTestMethod(PojoTestSetExecutor.java:104)
    at org.apache.maven.surefire.junit.PojoTestSetExecutor.execute(PojoTestSetExecutor.java:63)
    at org.apache.maven.surefire.junit.JUnit3Provider.executeTestSet(JUnit3Provider.java:131)
    at org.apache.maven.surefire.junit.JUnit3Provider.invoke(JUnit3Provider.java:93)
    at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:385)
    at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
    at org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:507)
    at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:495)
UTC: sun.util.calendar.ZoneInfo[id="UTC",offset=0,dstSavings=0,useDaylight=false,transitions=0,lastRule=null]
UT: sun.util.calendar.ZoneInfo[id="GMT",offset=0,dstSavings=0,useDaylight=false,transitions=0,lastRule=null]
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.044 s -- in de.e_nexus.web.rm.mail.TestDateParser

The Timezone UT clearly exists (might be similar or same like UTC) but Java does not support timezone UT afaict.

Is it save to rewrite UT to UTC?

What does "UT" stand for?

Most likely "universal time". But don't nail me down on it, somebody might actually ship an app where this is "Utah time"* (please don't). Time zones are a political matter after all...

"Universal time" should be called Coordinated Universal Time / UTC. timeanddate.com has a wrap-up of the basics. "UT" is potentially unclear in its meaning (is it UTC but not coordinated? Is it UT1 and somebody forgot the 1?). However, it can be found for example in the IANA tz database repo docs (example) or the RFC that describes the file format used to provide tz rules (example). Like UTC, it means solar time, not atomic time (TAI). There's a couple more related terms, see the UTC Etymology section on the wikipedia. TL;DR: use "UTC".

Is it save to rewrite unsupported timezone UT to UTC?

Datetime/Timezone libraries will accept "UTC" but less likely "UT". So you might want to replace it. TL;DR: Probably that's safe. Can you be absolutely sure it's not Utah time? No.

*) Utah does not have its own tz, US/Mountain (MST/MDT) is used there. An appropriate IANA tz db time zone identifier would be "America/Denver".