DateTime::RFC3339 was removed in 7.2 PHP version

I am working on this

Please find my patch below..

Bit out of scope, but many of the lines in the patch like
(new \DateTime())->setTimestamp($this->entity->getChangedTime())->setTimezone(new \DateTimeZone('UTC'))->format(\DateTimeInterface::RFC3339) lines can be updated to:
(new \DateTime('@' . $this->entity->getChangedTime())->format(\DateTimeInterface::RFC3339),
for readability. Since +0000 (UTC) is implied when using a timestamp directly:

php > echo (new \DateTime('@123456789'))->getTimeZone()->getName();
+00:00

The patch in #5 no longer applied cleanly, and I think there's one extra occurrence of DateTime::RFC3339 that needs to be changed.

@dpi, the default timezone cannot be relied on being UTC as it can be changed at the system level in php.ini, so we have to make sure that it is set correctly. See https://www.php.net/manual/en/datetime.configuration.php#ini.date.timezone

@John Cook

When using the @ notation with the datetime constructor it will always interpret as a time stamp. A time stamp is always UTC. It doesn’t matter what the default time zone is.

Check an example at https://3v4l.org/OSXkV

echo (new \DateTime('9am'))->format('r') . "\n";
date_default_timezone_set('Australia/Sydney');
echo (new \DateTime('9am'))->format('r') . "\n";
echo (new \DateTime('@123456789'))->format('r') . "\n";

Tue, 12 Apr 2022 09:00:00 +0200
Wed, 13 Apr 2022 09:00:00 +1000
Thu, 29 Nov 1973 21:33:09 +0000

Updated patch with reroll diff

Patch #10 could not apply. Tested on Drupal 9.3 and PHP 8.1. Got some errors and warnings.

#10 worked ok on 9.5 already. I re-rolled it once more just to make it apply more cleanly against 9.5.x.

This issue is being reviewed by the kind folks in Slack, #need-reveiw-queue. We are working to keep the size of Needs Review queue [2700+ issues] to around 200, following Review a patch or merge require as a guide.

D10 version needed
At this time we would need a D10.1.x patch or MR for this issue.

Since the aggregator module was removed in D10.

Also this may be more of a task vs a bug. If anyone disagrees feel free to change back but may need a special test or check for this? As it currently doesn't seem to break anything.

Patch updated against Drupal 10.1.x.

Took a while but the aggregator and hal modules were removed and BcTimestampNormalizerUnixTestTrait was deprecated.

Rest of the changes are included in the reroll.

was a random failure before.

This change feels a bit like change for change's sake. The issue summary needs to outline why we should do this. As per https://www.php.net/manual/en/class.datetime.php and https://3v4l.org/m7I6c the constant is still available on \DateTime - it's inherited from \DateTimeInterface.

What is the actual benefit of making this change?

Per #20

Answering the question in #20 is not suitable for a first time contributor to Drupal, so removing tag.

Since the MR doesn't need work right now, I am setting the status to what alexpott did.

@kim.pepper, your thoughts?

Assuming that the answer given in #25 is accepted, then a merge request needs to be created. And it was requested that the justification for the change be added to the issue summary, so I'm leaving that tag.

Updated the issue summary