If you are new to Joomla, please read Absolute basics of how a component works[^docs.joomla.org/Absolute_Basics_of_How_a_Component_Functions].

This tutorial is intended for Joomla 4. For information on creating a component for Joomla 3, see Developing a Model View Controller Component / 3.x[^docs.joomla.org/J3.x:Developing_an_MVC_Component].

You need Joomla 4.x for this tutorial. You can find Joomla 4 on GitHub[^github.com/joomla/joomla-cms] on the Developer Website[^developer.joomla.org/nightly-builds.html] or create a free website at launch.joomla.org.

Aim of this tutorial?

This tutorial does not create a practical example. I have intentionally kept everything general. My main goal is to show you how Joomla works - and to help you understand it better yourself. In the end, you replace the name 'foo' in all files with the name of your component and extend it with your special requirements. If you like, you can use the script duplicate.sh[^github.com/astridx/boilerplate/blob/t43/duplicate.sh] for this.

Therefore, this tutorial is primarily intended for programmers who want to create a new component and do not know Joomla yet. The tutorial is also a help for programmers of a Joomla 3 component, if they extend their component for Joomla 4. For example, if you are working on validating your Joomla 3 component, you will find what you need in the chapters on server-side and client-side validation - no more and no less.

The structure of this tutorial

Each chapter builds on the previous builds. However, if you are interested in a specific topic, feel free to look at a separate chapter. Be aware, however, that elements integrated in a previous chapter may be necessary.

Why this structure? There are many examples of components in the standard Joomla. For example

  • com_content
  • com_banner
  • com_tags or
  • com_contact

In each component you see implementation details in context. Each is complex and finding and separating certain elements, such as page numbering or custom fields, is a hassle. This tutorial focuses on one detail per chapter.

You create a component for Joomla 4, reusing the many existing implementations in Joomla. You are not reinventing the wheel. Joomla offers a whole range of standard functions.

If you want to get started immediately, scroll to The first view in the backend. Below you will find some things about Joomla 4 that you do not necessarily need for editing. However, some of them are good to know.


Joomla 4 offers five types of extensions

  • Components: A component fills the main content of the site. It usually uses data that is stored in the database.
  • Modules: A module is an add-on to the site that extends the functionality. It has a secondary part on the web page and is displayed at different positions. It is selectable on which active menu elements it is displayed. Modules are light and flexible extensions. They are used for small parts of the page that are less complex and are displayed across different components.
  • Plugins: A plugin processes the output generated by the system. It is not normally called as a separate part of the site. It takes data from other sources and manipulates it before output. A plugin works in the background.
  • Languages: The most basic extensions are languages. Essentially, language package files consist of key/value pairs that allow the translation of static text strings in the Joomla source code.
  • Templates: A template defines the design of your Joomla website.

Joomla 4 consists of five different applications

  • Installation (used to install Joomla and must be deleted after installation);
  • Administrator (backend - to manage content);
  • Website (frontend - used to display content);
  • CLI (used to access Joomla from the command line and for cron jobs);
  • API (Web Services - used to create APIs for machine-accessible content);

Basic knowledge

Development environment

This text is about the Joomla code. It is not about the latest tools for developers. However, a few things are essential.

Test environment

You want to program an extension for Joomla and therefore need an environment in which Joomla is installed. In my opinion, a XAMPP server package[^www.apachefriends.org/index.html] on a local workstation is an ideal prerequisite for developing new extensions. The direct access to the files of Joomla in the local file system facilitates the handling.

Code editors or IDE

A good editor is also essential. This should be one you feel comfortable with. Wikipedia maintains a list of editors.[^en.wikipedia.org/wiki/List_of_text_editors].

More convenience is offered by an integrated development environment IDE. By convenience I mean functions like

  • versioning: integration of GIT[^wikipedia.org/wiki/Git]
  • Code completion: Complement user input in a meaningful way
  • Syntax highlighting: colour highlighting of variables, class names or statements.
  • Coding standards: Observance of rules
  • Debugging: Finding errors

You can also get an overview of IDEs from Wikipedia using a List of IDEs[^en.wikipedia.org/wiki/Comparison_of_integrated_development_environments].

In the Joomla community, the IDE PHPStorm[^www.jetbrains.com/phpstorm/], which is subject to a fee, is popular. Users of Visual Studio Code[^code.visualstudio.com/] are becoming increasingly common. Also worth mentioning are NetBeans and Eclipse.

Are you looking for instructions on how to set up the development environment? Joomla with Visual Studio Code can be found in the Joomla Documentation[^docs.joomla.org/Visual_Studio_Code]. For PHPStorm, Jetbrains provides a description.

If you like, you can read my first steps with Visual Studio Code at blog.astrid-guenther.de/ubuntu-vscode-docker-lamp.

Joomla 3 and Joomla 4 in comparison

New in Joomla 4

Frontend and Backend accessible and with Bootstrap 5

Joomla 4 integrates Bootstrap 5 into the Joomla core. Thereby, the included templates are accessible and correspond to level AA of WCAG 2.1. WCAG 2.1 complements WCAG 2.0 and is the web standard for digital accessibility, which is mandatory for public bodies in the European Union. As an extension developer, it is not mandatory that you use Bootstrap 5. But technically it should comply with the latest standards. It would be a shame not to use the good template that Joomla offers.

Optimised Web Assets

With a single call, Web Assets allow developers to load multiple Javascript and CSS files in a specified order. For example, if an extension developer uses styles that depend on Font Awesome being loaded first and they know that Joomla 4 uses the icon font set, Web Assets come into play. Web Assets are described in several places in this tutorial.

Use the Web Asset Manager when developing for Joomla 4. All calls to HTMLHelper::_('stylesheet or script ...) work, but these assets are appended after the Web Asset Manager assets. This results in overriding styles that are set in the template. Thus, a user does not have the possibility to manipulate by means of a user.css. See in this context (Issue 35706)https://github.com/joomla/joomla-cms/issues/35706.

Web Services enable automated data exchange

Joomla 4 web services make content accessible to other websites or mobile applications. What is a web service? Different definitions cause confusion. The SOAP standards are referred to as web services. Others know them under the term REST API. The W3C generally defines a web service as an interface for automated communication via computer networks. The API integration in Joomla 4 implements such an interface in the core of the CMS with the help of REST. In the example we are building in this text, we also support the Joomla API.


With the new Workflow component, it is possible to link website content to a workflow. Thirt Party extensions can also offer a workflow with the core extension. This function is not yet included here in the book.

Many other changes and improvements

Joomla 4 includes new security features such as support for prepared statements for database systems. This prevents SQL injection because the database checks the validity of parameters. In addition, the code base has been restructured. The code was thoroughly cleaned up, obsolete functions removed and PHP namespaces introduced.

Backwards compatibility with Joomla 3

This text is primarily written for developers who are starting a new extension. Nevertheless, issues related to compatibility with Joomla 3 are of interest. A page in the Joomla documentation[^docs.joomla.org/Potential_backward_compatibility_issues_in_Joomla_4] summarises the important points.

Never change the core files

The purpose of Joomla extensions is to have a system that can be extended. It is possible that your code and Joomla Core code can be provided with new functions independently of each other.

If make changes to Joomla itself, these will be overwritten with the next update.

You have the feeling that your function can only be implemented with a core hack? Your feeling is wrong! There is always a solution that leaves the system files untouched.

Learn from the core files

That you should not change the system files does not mean that you do not even look at them. Quite the opposite! By reading you will come across lots of code that is not documented anywhere. If you are not sure how to best implement a function, just rummage around in the Joomla code. The solution is usually be found in the heart of Joomla.

The autoload_psr4.php file

During the installation, entries are made in /administrator/ cache/autoload_psr4.php. This is new in Joomla 4. If you encounter strange problems, delete this file. It will be recreated the next time you load. Sometimes this solves a problem.

The following text was added to the README on Github using the PR 28436[^github.com/joomla/joomla-cms/pull/28436]: "Joomla creates a cache of the namespaces of its extensions in JOOMLA_ROOT/administrator/ cache/autoload_psr4.php. If extensions are created, deleted or removed in git then this file needs to be recreated. You can simply delete the file and it will be regenerated on the next call to Joomla."


Note the namespace entry at the top of most PHP files.

Namespace FooNamespace\ Component\Foos\Administrator\View\Foos;

and as a tag in the manifest file

<Namespace>FooNamespace\ Component\Foos</ Namespace>.

Remember to include the path="src" parameter if you put the namespace files in the src subdirectory. This is common in Joomla and the sample extensions created in this tutorial also use this directory[github.com/astridx/boilerplate/blob/62a970704ee2899addd3922e88c918b7f6af72a2/ src/administrator/components/com_foos/foos.xml#L12].

Why use namespaces? All PHP classes are thus organised in a defined structure and automatically loaded via the Classloader. Thereby ContentModelArticles becomes Joomla\Component\Content\ Administrator\Model\ArticlesModel.

JLoader can process the namespaces automatically and distinguishes between front-end and back-end classes.

Files with namespaces can be found in the directory /src[^github.com/joomla/joomla-cms/pull/27687]

Capitalisation of folder and file names

You will notice that some of the Joomla 4 folder and file names start with upper case letters and others with lower case letters. At first glance, this seems unstructured. At second glance it makes sense.

The folders in upper case contain PHP classes with namespace. Those in lower case contain XML files, template files. There are a few lower case folders that contain PHP files. These are necessary to ensure compatibility with Joomla 3. Often these are helper files.

For more information, see: github.com/joomla/joomla-cms/issues/22990.

Meaningful class names

The component MVC classes have more meaningful names in Joomla 4. For example, the controllers now have controller as a suffix for their class name. Thus, FooNamespace\Component\Foos\ Administrator\Controller\Foos becomes FooNamespace\Component\Foos\ Administrator\Controller\ FoosController.

Additionally, the default controller, which in Joomla 3 is just called Controller, gets the name DisplayController to better reflect what the class does. See: https://github.com/joomla/joomla-cms/pull/17624


Do you need an empty file index.html in each folder of your component? The index.html is no longer needed, as that is directory listings not allowed in the default configuration[^github.com/joomla/joomla-cms/pull/4171]. If you are further interested read the discussion on the topic in the Google Group[^groups.google.com/forum/#!topic/joomla-dev-cms/en1G7QoUW2s].

Technical requirements

Do you know how those responsible at Joomla decide which functions are supported and what is not pursued further? That's what the statistics plugin[^developer.joomla.org/about/stats.html] is for. Thanks to the users who activate this extension, important information flows into the development.

Why is a blank line inserted at the end of a source code file in Joomla files?

There are several reasons why a blank line at the end of a file is included as a requirement in the Joomla Coding Standards:

  • Apart from the fact that it is a nicer cursor position when you go to the end of a file in a text editor, a line break at the end of the file allows you to easily check that the file has not been truncated.
  • When you paste something at the end of a file, the difference display in Git shows that you've changed the last line, when the only thing you've actually pasted is a line break. This is confusing.
  • Today it doesn't matter, but: many older tools in the programming field misbehave if the last line of data in a file is not terminated with a newline or a carriage return/newline combination.


Why should you omit the closing tag of PHP sections at the end of a file?

The closing tag of a PHP block at the end of a file is optional, and in some cases it is helpful to omit it. By omitting the closing tag, you can avoid accidentally inserting spaces or line breaks at the end of the file. For further explanation, see php.net[php.net/basic-syntax.instruction-separation].

PHP operators for equality (== two equal signs) and identity (=== three equal signs)

The [comparison operator](https://www.php.net /manual/en/language.operators.comparison.php #language.operators.comparison)[php.net/manual/en/language.operators.comparison.php #language.operators.comparison] == compares between two different types if they are different, while the === operator performs a type-safe comparison. This means that it returns true only if both operands have the same type and the same value. Examples:

1 === 1: true 1 == 1: true 1 === "1": false // 1 is an integer, "1" is a string 1 == "1": true // "1" is converted to an integer, which is 1 "foo" === "foo": true // both operands are strings and have the same value

Note: Two instances of the same class with equivalent elements will be evaluated by the operator with three equal signs === with false. Example:

$a = new stdClass();
$a->foo = "bar";
$b = clone $a;
var_dump($a === $b); // bool(false)

In Joomla, we use type-safe comparison whenever possible because it is more accurate.

Single quotes and double quotes

In Joomla, we use single quotes. Using single quotes is more performant, usually more readable and more straightforward when used with associative arrays. PHP does not need any additional processing to interpret what is inside the single quote. If you use double quotes, PHP must check to see if there are any variables in the string.

More information about this and the explanation of two other ways to use strings in PHP can be found on the website php.net[^php.net/manual/en/language.types.string.php].

Single quotes

The simplest way to specify a string is to enclose it in single quotes. Single quotes are generally faster, and anything enclosed in quotes is treated as a single string. Example:

echo 'Start with a single string';
echo 'String with \' apostrophe';
echo 'String with a php variable' . $name;
Double quotes

Use double quotes in PHP to avoid using a period when separating. Use curly braces {} in strings to enclose variables if you don't like to use the concatenation operator (.). Example:

var $name = "Peter";
echo "Hello {$name}"

Alternative syntax for control structures

PHP offers an additional notation for control structures. This is especially handy when outputting larger blocks of HTML directly - without using echo. Use them in template files. This way they remain clear.


<?php foreach ($this->items as $i => $item) : ?>
<?php echo $item->name; ?>
<?php endforeach; ?>

instead of

foreach ($this->items as $i => $item) {
	echo $item->name;
	echo '</br>';

In this way, a single line is self-contained and the HTML code is still clearly structured.

Database table prefix

As an extension developer, you ideally develop your extension so that the database prefix is variable. For this purpose, one uses the string #__. The string #__ is replaced with the correct prefix at runtime by Joomla.

JavaScript, CSS and image files?

Where do you best store JavaScript, CSS and image files? Store these data in the directory media in the Joomla root directory. This way it is possible to overwrite them. This is particularly advantageous for CSS files to make the design of the whole Joomla Website consistent. The Best Practice Guidelines[^docs.joomla.org/Development_Best_Practices] also recommend this.

Examples: For this tutorial extension I will later use media/com_foos/js/ for the JavaScript files of the component. The CSS files of the module mod_articles_news can be found in the directory media/mod_articles_news/css/. And the images for the plugin plg_content_vote are in the folder media/plg_content_vote/images/.

Fontawesome Icons

You want to use icons but don't want to add your own library. Use the free icons from fontawesome.com/icons in the frontend and backend. At least if you use the standard templates Cassiopeia and Atum, this will work. If your template does not support FontAwesome, you can load the icons yourself via the WebassetManager. In Joomla Fontawesome is delivered with the template. Marking them as dependency[^templates/cassiopeia/joomla.asset.json] is sufficient.

Attention: In Joomla Core files, you cannot simply copy them, because Joomla add the text icon- in front of the icon name. This is then converted via the file build/media_source/ system/scss/_icomoon.scss for Fontawesome. In this way, only the icons included in the previously mentioned file will work. Why does Joomla complicate the selection of Font Awesome icons? The reason for this is as follows: Extensions that were programmed for Joomla 3 can still be used.

The HTML code

<i class="fas fa-align-left"></i>

displays the left-aligned character, for example.

Use images

A new JLayout[^gist.github.com/dgrammatiko/a20236039586a2fbc5c77caadffc3de8] as of Joomla 4.0.5 allows developers to output HTML image tags easily:

So instead of writing something like this:


'; ?>

The recommended way is to use the JLayout:

echo LayoutHelper::render('joomla.html.image', ['src' => imageURL, 'alt' => $imageAlt]);


  • The URL and the alt attribute are escaped correctly.
  • The developer does not have to worry about the "#" at the end of the URL.
  • The image tag gets a loading="lazy" attribute if the image has the width and height attributes defined.
  • The alt attribute is ignored if the value passed is false.
  • All other attributes are rendered correctly, pass them as in the array (for example 'class' => 'my-class').


An error occurred in one of my Joomla extensions. Dates and times were not displayed correctly. The time zone was obviously the problem. The solution seemed simple at first glance. I had worked with dates and the class DateTime in PHP [^php.net/manual/en/class.datetime.php] in the past and had experience with time zones. In Joomla, however, there are special features.

Let's look at my concrete problem. A user who lives in the time zone 'Australia/Adelaide' (UTC/GMT +10:30 hours) fills out a form in the summer which contains a field in which a date is stored. The timezone 'Australia/Adelaide' has a difference to the timezone 'UTC' of +10:30 hours in summer, in wintertime the difference is +9:30 hours.

Joomla 4 | Set time zone at user

The server is located in Johannesburg, thus in South Africa. The time zone of the server is set to 'Africa/Johannesburg' in the global configuration. The time zone 'Africa/Johannesburg' has a difference to the time zone 'UTC' of +2:00 hours in summer time, in winter time the difference is +1:00 hours.

Joomla 4 | Set time zone of the server in the global configuration

My extension is a contest. The date is 4.10.2022. The time is 00:00:01. That is exactly when the competition ends. It is important that the game is made inactive at the same time all over the world. This is different from, for example, an Advent Calendar. With the Advent calendar, it may be intentional that something happens at a certain time in each time zone. The first door opens in Australia, in Africa and in Europe when it is locally the 1.12. and not at the same time.

I use the field of type Calendar [^docs.joomla.org/Calendar_form_field_type] in the form under Joomla.


To my surprise, I notice during my first tests that instead of 2022-10-04 00:00:01 the string 2022-10-03 13:30:01 is stored in the database. With a little research, I realise that the calendar field converts the date to the UTC time zone and stores it in this form. The information about the time zone itself is not stored in the database. The latter is not necessary if it is ensured that one and the same time zone is always used. In the case of Joomla, this is UTC.

In the code for the calendar field of the file /libraries/src/Form/Field/CalendarField.php this process can be read in the function filter:

public function filter($value, $group = null, Registry $input = null)
    // Make sure there is a valid SimpleXMLElement.
    if (!($this->element instanceof \SimpleXMLElement)) {
        throw new \UnexpectedValueException(sprintf(‚%s::filter `element` is not an instance of SimpleXMLElement‘, \get_class($this)));

    if ((int) $value <= 0) {
        return ‚‚;

    if ($this->filterFormat) {
        $value = DateTime::createFromFormat($this->filterFormat, $value)->format(‚Y-m-d H:i:s‘);

    $app = Factory::getApplication();

    // Get the field filter type.
    $filter = (string) $this->element[‚filter‘];

    $return = $value;

    switch (strtoupper($filter)) {
        // Convert a date to UTC based on the server timezone offset.
        case ‚SERVER_UTC‘:
            // Return an SQL formatted datetime string in UTC.
            $return = Factory::getDate($value, $app->get(‚offset‘))->toSql();

        // Convert a date to UTC based on the user timezone offset.
        case ‚USER_UTC‘:
            // Get the user timezone setting defaulting to the server timezone setting.
            $offset = $app->getIdentity()->getParam(‚timezone‘, $app->get(‚offset‘));

            // Return an SQL formatted datetime string in UTC.
            $return = Factory::getDate($value, $offset)->toSql();

    return $return;

The variable $value contains the value entered by the user, in this case 2022-10-04 00:00:01. This is converted to the time zone UTC and then stored in the variable $return. The converted value is passed to the database for saving. This way you can always be sure that the date stored in the database for the time zone UTC is correct.

In Joomla, SERVER_UTC and USER_UTC offer the possibility of outputting the date either in the time zone with which the web server is configured or in the time zone set by the user. In short, the constants indicate whether the value of the variable $value is in the time zone stored at the user or the time zone of the webserver, which is configurable in the global configuration.

Why is the date converted to the time zone UTC for saving in the database? Actually, it doesn't matter which time zone you choose. It makes sense to define one. That way you always have a fixed starting point. Otherwise, you would have to determine the conversion factor or offset for each time zone combination. Joomla's standard behaviour ensures that the date stored in the database is correct for the UTC time zone and that only the difference/offset to this time zone is needed for the conversion.

The default time zone can be configured in the file configuration.php. The variable is called $offset. The default is public $offset = 'UTC';. When displaying the time in the frontend of the website, one now only has to calculate the difference between UTC and the desired time zone.

The class Joomla\CMS\Date

If you look at the class Joomla\CMS\Date in the directory /libraries/src/Date/Date.php, you will notice that the constructor public function __construct($date = 'now', $tz = null) allows two parameters: the date and the timezone.

public function __construct($date = ‚now‘, $tz = null)
    // Create the base GMT and server time zone objects.
    if (empty(self::$gmt) || empty(self::$stz)) {
        // @TODO: This code block stays here only for B/C, can be removed in 5.0
        self::$gmt = new \DateTimeZone(‚GMT‘);
        self::$stz = new \DateTimeZone(@date_default_timezone_get());

    // If the time zone object is not set, attempt to build it.
    if (!($tz instanceof \DateTimeZone)) {
        if (\is_string($tz)) {
            $tz = new \DateTimeZone($tz);
        } else {
            $tz = new \DateTimeZone(‚UTC‘);

    // Backup active time zone
    $activeTZ = date_default_timezone_get();

    // Force UTC timezone for correct time handling

    // If the date is numeric assume a unix timestamp and convert it.
    $date = is_numeric($date) ? date(‚c‘, $date) : $date;

    // Call the DateTime constructor.
    parent::__construct($date, $tz);

    // Restore previously active timezone

    // Set the timezone object for access later.
    $this->tz = $tz;

The class Joomla\CMS\Date is used, among other things, in the function getDate of the file /libraries/src/Factory.php, which helps Joomla extension programmers to always output the date with the appropriate offset, i.e. in the correct time zone. The code of the function getDate() is printed below for the sake of completeness:


public static function getDate($time = ‚now‘, $tzOffset = null)
    static $classname;
    static $mainLocale;

    $language = self::getLanguage();
    $locale = $language->getTag();

    if (!isset($classname) || $locale != $mainLocale) {
        // Store the locale for future reference
        $mainLocale = $locale;

        if ($mainLocale !== false) {
            $classname = str_replace(‚-‘, ‚_‘, $mainLocale) . ‚Date‘;

            if (!class_exists($classname)) {
                // The class does not exist, default to Date
                $classname = ‚Joomla\\CMS\\Date\\Date‘;
        } else {
            // No tag, so default to Date
            $classname = ‚Joomla\\CMS\\Date\\Date‘;

    $key = $time . ‚-‘ . ($tzOffset instanceof \DateTimeZone ? $tzOffset->getName() : (string) $tzOffset);

    if (!isset(self::$dates[$classname][$key])) {
        self::$dates[$classname][$key] = new $classname($time, $tzOffset);

    $date = clone self::$dates[$classname][$key];

    return $date;

How do you display the date in the correct time zone in your Joomla extension in the frontend? You are on the safe side if you use the functions provided by Joomla. Let's take a look at the interaction of Factory::getDate() and the class Joomla\CMS\Date in Joomla as an example below.

Display in the frontend

The value in the database

Let's start very simply. The following code displays the string that is stored for the date in the database.

echo $this->item->advent_publish_up;

The Output is:

2022-10-03 13:30:01

I have already explained why the time is displayed in the UTC time zone.

The time in the time zone of the logged-in user

If you want to display the date in the time zone that is stored with the user, the following code shows a possibility.

$date = Factory::getDate($this->item->advent_publish_up, 'UTC');
$user = Factory::getApplication()->getIdentity();
echo $this->value = $date->format('Y-m-d H:i:s', true, false);
echo "<br><pre>";
echo "</pre>";

If a user is logged in with the time zone set to Australia/Adelaide, the following text appears in the frontend:

2022-10-04 00:00:01

Joomla\CMS\Date\Date Object
    [tz:protected] => DateTimeZone Object
            [timezone_type] => 3
            [timezone] => Australia/Adelaide

    [date] => 2022-10-04 00:00:01.000000
    [timezone_type] => 3
    [timezone] => Australia/Adelaide

If no user is logged in, the time zone of the server is fallback. In our example, the following text appears:

2022-10-03 15:30:01

Joomla\CMS\Date\Date Object
    [tz:protected] => DateTimeZone Object
            [timezone_type] => 3
            [timezone] => Africa/Johannesburg

    [date] => 2022-10-03 15:30:01.000000
    [timezone_type] => 3
    [timezone] => Africa/Johannesburg

The following code displays the date in the time zone stored for the web server in the global configuration.

$date = Factory::getDate($this->item->advent_publish_up, 'UTC');
$date->setTimezone(new \DateTimeZone(Factory::getApplication()->get('offset')));
echo $this->value = $date->format('Y-m-d H:i:s', true, false);
echo "<br><pre>";
echo "</pre>";

The Output is:

2022-10-03 15:30:01

Joomla\CMS\Date\Date Object
    [tz:protected] => DateTimeZone Object
            [timezone_type] => 3
            [timezone] => Africa/Johannesburg

    [date] => 2022-10-03 15:30:01.000000
    [timezone_type] => 3
    [timezone] => Africa/Johannesburg

The following code outputs the date immediately in the standard time zone UTC.

$date = Factory::getDate($this->item->publish_up, 'UTC');
echo $this->value = $date->format('Y-m-d H:i:s', true, false);
echo "<br><pre>";
echo "</pre>";

The Output is:

2022-10-03 13:30:01

Joomla\CMS\Date\Date Object
    [tz:protected] => DateTimeZone Object
            [timezone_type] => 3
            [timezone] => UTC

    [date] => 2022-10-03 13:30:01.000000
    [timezone_type] => 3
    [timezone] => UTC

Conclusion: Depending on the use case, i.e. whether it is a competition where everything should happen at the same time or an Advent calendar where the actual time is relevant, the date can be programmed in the Joomla extension.