[MySQL] Timezone support was added on version 8.0.19

[phansys]

Q	A
Type	bug
Fixed issues	n/a

Summary

This bug was detected after adding the functional test for the timezone aware fields in #6006.

• In MySQL, support for timezone offsets was added in 8.0.19.
• In MariaDB, there is no support for timezones in timestamps (see this task and this task);

ToDo

• Check how to refactor or split getDateTimeTzFormatString() in two methods (one for convertToDatabaseValue() and the other for convertToPHPValue()) because for INSERT / UPDATE the timezone offsets are allowed, but on SELECT the returned format is always an UTC timestamp (without offset), as it is how MySQL persists the timestamps;
• Add tests;

[derrabus]

It does not look like MySQL supports storing a date with a timezone, given that the timezone information is lost after insertion, does it?

[phansys]

It does not look like MySQL supports storing a date with a timezone, given that the timezone information is lost after insertion, does it?

Yes, I have the same understanding. See #6014.

[derrabus]

But then we cannot really map it to the datetimetz type because the timezone you insert is not the timezone you fetch from the database.

[phansys]

But then we cannot really map it to the datetimetz type because the timezone you insert is not the timezone you fetch from the database.

IMO, it depends on the behavior we expect about the "datetimetz" and how clear we are in our docs about the results in each case. In this case, I think we can indicate that the behavior is not "symmetric" but only works for writing. The same occurs with other platforms.

[derrabus]

I know, we were very vague about that and did not cover the behavior in tests. So every developer that used those types made their own assumptions on how they worked. The expected behavior is thus the currently implemented one, which means we cannot really change it without breaking stuff downstream.

See also my comment in #6006 (comment).

Shall we rather deprecate the current types and start from scratch? I think, this would make sense, given the inconsistency that we currently uncover regarding those types.

[github-actions]

There hasn't been any activity on this pull request in the past 90 days, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 7 days.
If you want to continue working on it, please leave a comment.

[github-actions]

This pull request was closed due to inactivity.