The comments to go with the line 384 you're mentioned are actually incorrect. RFC2822 in section 3.1, paragraph 3 it is stated that "These "obs-" elements refer to tokens defined in the obsolete syntax in section 4.  In all cases, these productions are to be ignored for the purposes of generating legal Internet messages and MUST NOT be used as part of such a message." As the comment deals with *generating* a date time string as part of a format, it is invalid to mention those obsolete timezones specifications. The nonterminals in the 2822 rfc starting with "obs-" are obsolete parts of the old (RFC 822) standard. We state in the manual (http://no2.php.net/timezones) which time zones we support, and "UT" is not one of those. First of all those timezone names from from a standardized timezone database, and secondly, UT would be semantically wrong as is explained in bug #42486.

In contrast, 4. Obsolete Syntax [RFC 2822] puts a receiver (e.g. strtotime()) into the obligation to support all of those:

   Though some of these syntactic forms MUST NOT be generated according
   to the grammar in section 3, they MUST be accepted and parsed by a 
   conformant receiver. This section documents many of these syntactic
   elements.  Taking the grammar in section 3 and adding the
   definitions presented in this section will result in the grammar to
   use for interpretation of messages.

from: ://datatracker.ietf.org/doc/html/rfc2822#section-4

As strtotime() is not about generating but parsing, this is a regression in PHP 5.1.0 and ongoing: ://3v4l.org/esuFG

PHP 4.3.0 - 4.3.11, 4.4.0 - 4.4.9, 5.0.0 - 5.0.5 strtotime() is RFC 2822 conform for zone "UT" (the reported regression):

    UT: 1189612152
    Z.: 1189612152

PHP 5.1.0 and later strtotime() errors (returns false) for zone "UT":

    UT: 
    Z.: 1189612152


And it does not get easier.


> We state in the manual (http://no2.php.net/timezones) which time zones we support, and "UT" is not one of those.

While this is correct information, even today more than 15 years after the original comment, it is that "zone" identifiers not therein *are* supported, for example A-Z (excluding J, taken from "obs-zone" [RFC 2822]), which means they are from the obsolete syntax, and therefore fall under the requirement of RFC 2822 and

    they MUST be accepted and parsed by a conformant receiver.

Just like "UT" which remains unsupported by PHP. Cf. ://3v4l.org/RckQr

Therefore the statement in the manual about the supported zone identifiers is inclusive and not exclusive and the listing itself not definitive or overly specific.

Furthermore, that `" "UT" is not one of those "`, is merely informative and should not lead towards a conclusion that it should not be supported as that would be misleading as other strtotime() supported zones are also not part of that list.  (And everything else would be destructive in regards of internet standards and PHP itself.)

Two more explanations I'd also like to comment on:

> First of all those timezone names from a standardized timezone database, and secondly, UT would be semantically wrong as is explained in bug #42486.

The "First" part may create the impression as if the RFC corpus would not qualify as a standardized database in itself, nor that RFC 822 and RFC 2822 specifically nominate zone (or timezone) values structurally organized.

This is far away from reality, both RFCs are part of a profound standardization process and the syntax of the zones are well defined, RFC 822 is an Internet Standard, and RFC 2822 a Proposed Standard in the Standards Track.

The second part relates to the explanation in bug #42486:

    UT is not really a easy measurable timezone, unlike UTC. To support
    this correctly we should take care of leapseconds, and this is very
    much something you don't want to do. See
    ://en.wikipedia.org/wiki/DUT1 for what is different between UTC and
    UT.

According to Wikipedia, UT (short for Univeral Time) is not a timezone but a time standard.  In this bug report, "UT" [RFC2822] is a (time) zone.

Without mentioning that indeed "UT" was supported by strtotime() previously and the meaning of "UT" as zone [RFC 2822] should have been self-explanatory, it is even that supporting "UT1" has never been asked for.  It would have made little sense anyway as RFC 2822 does not mention a zone - obsolete or not - with the code "DUT1" or even "UT1".

The reference to the Wikipedia therefore appears unrelated at best, and the speculation about future leapseconds support in strtotime() remains as an interesting, but nevertheless little productive remark in getting a regression out of the way.

All in all this does not stand the test of time. Let's review the original problem statement:

> http://bugs.php.net/bug.php?id=42486 was closed as won't fix, but this means we can't parse valid rfc2822 strings.

Yes, this is correct, strtotime() since PHP 5.1.0 can not parse internet date and time in the "UT" zone in a conformant way to the intent of RFC 2822 any longer.  It was able to do so previously.

Unfortunately, this statement stands correct until today.

The original decision to not fix this looks bogus to me.

Hopefully the reasons or constraints that prevented a fix 15+ years ago to remove the regression are finally gone and original support for "UT" in strtotime() can be restored.