MDEV-29564: Add ISO 8601 support (%L and %o) to DATE_FORMAT

[abhishek593]

This PR enhances DATE_FORMAT() by adding two new format specifiers to support ISO 8601 compliant timestamps:

• %L: Outputs 3-digit milliseconds (derived from second_part / 1000).
• %o: Outputs a colon-separated UTC offset (e.g., +05:30).

Also, added test cases for verification.

[vuvova]

code-wise it's very good. May be I'd combine 'o' and 'z' to reduce code duplication, like

  case 'z':
  case 'o':
     ...
     if (wc == 'o') str->append(':');

Letters that you've chosen 'L' and 'o' are perfect. Unlike some other letters that DATE_FORMAT uses already, these two are not used by date(1) or strftime(3), so there will be no conflict or user confusion.

Still, while the PR is good, I'm not quite sure we should add two more arbitrary letters to the arbitrary list of formats in DATE_FORMAT. Especially because existing

DATE_FORMAT(dt, '%Y-%m-%dT%H:%i:%S.%f%z')

is perfectly ISO 8601 compatible, according to https://en.wikipedia.org/wiki/ISO_8601.

Let's see if someone will have a stronger opinion of what to do with it.

[abhishek593]

I agree regarding 'L'. We should drop it. I added it because I misunderstood Jira example.
We can also drop 'o', and instead add support for using '%:z' (instead of %z) for printing with colons as supported in (https://www.gnu.org/software/coreutils/manual/html_node/Time-conversion-specifiers.html). Are you aligned with this?

[gkodinov]

Thank you for your contribution!

This is preliminary review. I object to the choice of formatting specifiers. I believe we need to converge to industry standards here. And if two major databases are doing it in a certain way this is as close as industry standards as it gets in my book.

[gkodinov]

How did you come up with the %L thing?
Both Oracle's TO_DATE() and posgtgresql's to_char use the following:

• FF1 tenth of second (0–9)
• FF2 hundredth of second (00–99)
• FF3 millisecond (000–999)
• FF4 tenth of a millisecond (0000–9999)
• FF5 hundredth of a millisecond (00000–99999)
• FF6 microsecond (000000–999999)

I'd suggest to at least strive towards the same. It's OK to keep %f as equivalent of %FF6.
Oracle even goes to FF9!

[gkodinov]

Again, both postgresql and oracle use %TZH and %TZM for time zone hours and timezone minutes. I'd suggest sticking with the same! I know this will change the meaning of a (possibly existing) format string "%TZH" from "12:14:16ZH" to "+01". But I guess this is an incompatible change we should be willing to take.

[abhishek593]

@gkodinov Thanks for the feedback! Adopting Oracle and PostgreSQL conventions makes sense. Regarding 'L', I just thought of a new character based on Jira description (It mentioned milliseconds, so I thought we need exactly 3 digits). I am happy to update the implementation to support FFn, TZH/M. However, I saw on Jira that you changed the status to Stalled (I don't exactly know what that means in this context). So, should I continue to work on this or you want to drop it for now?