### Apache Airflow version

2.2.3 (latest released)

### What happened

When issuing the following command:

`airflow dags trigger 'VMWARE_BACKUP'  --conf '{"VM_NAME":"psfiplb1"}'`

the system replays with:

```
/usr/local/lib/python3.8/dist-packages/airflow/api/common/experimental/trigger_dag.py:85 DeprecationWarning: Calling `DAG.create_dagrun()` without an explicit data interval is deprecated
Created <DagRun VMWARE_BACKUP @ 2021-12-31T00:00:00+00:00: manual__2021-12-31T00:00:00+00:00, externally triggered: True>
```

### What you expected to happen

I have no other switch parameter to choose for avoiding the deprecation warning.

My concern is about what will happen to the command when the deprecation will transforms itself in an error.

### How to reproduce

_No response_

### Operating System

Ubuntu 20.04.3 LTS

### Versions of Apache Airflow Providers

apache-airflow-providers-celery==2.1.0
apache-airflow-providers-ftp==2.0.1
apache-airflow-providers-http==2.0.1
apache-airflow-providers-imap==2.0.1
apache-airflow-providers-microsoft-mssql==2.0.1
apache-airflow-providers-microsoft-winrm==2.0.1
apache-airflow-providers-openfaas==2.0.0
apache-airflow-providers-oracle==2.0.1
apache-airflow-providers-samba==3.0.1
apache-airflow-providers-sftp==2.3.0
apache-airflow-providers-sqlite==2.0.1
apache-airflow-providers-ssh==2.3.0

### Deployment

Virtualenv installation

### Deployment details

Airflow inside an LXD continer

### Anything else

_No response_

### Are you willing to submit PR?

- [ ] Yes I am willing to submit a PR!

### Code of Conduct

- [X] I agree to follow this project's [Code of Conduct](https://github.com/apache/airflow/blob/main/CODE_OF_CONDUCT.md)

args = self.parser.parse_args(self.task_args)
        args.external_executor_id = "ABCD12345"
        with mock.patch.dict(os.environ, {"external_executor_id": "12345FEDCBA"}):
            task_command.task_run(args)
            mock_local_job.assert_called_once_with(
                task_instance=mock.ANY,
                mark_success=False,
                pickle_id=None,
                ignore_all_deps=False,
                ignore_depends_on_past=False,
                wait_for_past_depends_before_skipping=False,
                ignore_task_deps=False,
                ignore_ti_state=False,
                pool=None,
                external_executor_id="ABCD12345",
            )
    @pytest.mark.parametrize("is_k8s", ["true", ""])
    def test_logging_with_run_task_stdout_k8s_executor_pod(self, is_k8s):
        """
        When running task --local as k8s executor pod, all logging should make it to stdout.
        Otherwise, all logging after "running TI" is redirected to logs (and the actual log
        file content is tested elsewhere in this module).
        Unfortunately, to test stdout, we have to test this by running as a subprocess because
        the stdout redirection & log capturing behavior is not compatible with pytest's stdout
        capturing behavior.  Running as subprocess takes pytest out of the equation and
        verifies with certainty the behavior.
        """