Add a note about the support and the behavior of the "datetimetz" type

Author: phansys

docs/en/reference/known-vendor-issues.rst

@@ -70,8 +70,8 @@ MySQL
 DateTimeTz
 ~~~~~~~~~~
 
-MySQL does not support saving timezones or offsets. The DateTimeTz
-type therefore behaves like the DateTime type.
+Previous to version 8.0.19, MySQL does not support saving timezones or offsets. The DateTimeTz
+type therefore behaves like the DateTime type on previous versions.
 
 Sqlite
 ------
@@ -104,8 +104,8 @@ when trying to convert database values to ``\DateTime`` objects using
 DateTimeTz
 ~~~~~~~~~~
 
-Sqlite does not support saving timezones or offsets. The DateTimeTz
-type therefore behaves like the DateTime type.
+Sqlite support saving timezone offsets, but this feature is not yet implemented in DBAL.
+The DateTimeTz type therefore behaves like the DateTime type.
 
 Reverse engineering primary key order
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

docs/en/reference/types.rst

@@ -301,6 +301,15 @@ information, you should consider using this type.
 Values retrieved from the database are always converted to PHP's ``\DateTime`` object
 or ``null`` if no data is present.
 
+.. note::
+
+    This type is not supported by all the vendor platforms or by all of their versions. Depending on
+    these variants, the databases that support this type may return the persisted date and time in a
+    different timezone than the one used during the ``INSERT`` or the ``UPDATE`` operation. This means
+    that if you persist a value like `1986-22-03 19:45:30-03:00`, you could have `1986-22-03 22:45:30-00:00`
+    as the result of a ``SELECT`` operation for that record. In these cases, the timezone offset present
+    in the result is usually UTC or the one configured as default in the database server.
+
 datetimetz_immutable
 ^^^^^^^^^^^^^^^^^^^^