The code in Item_temporal_hybrid_func::fix_temporal_type() is not friendly for new data types.
Soon we'll need to support new data types for ADDTIME() and DATEADD() (see MDEV-15750, MDEV-11829, MDEV-10018)

We'll remove this method and change val_str_ascii() as follows:

 String *Item_temporal_hybrid_func::val_str_ascii(String *str)

 {

   DBUG_ASSERT(fixed == 1);

   MYSQL_TIME ltime;

-  if (get_date(&ltime, 0) || fix_temporal_type(&ltime) ||

+  if (get_date(&ltime, 0) ||

       (null_value= my_TIME_to_str(&ltime, str, decimals)))

     return (String *) 0;

Instead of fix_temporal_type(), we'll add data type conversion functionality directly inside get_date() implementations for the descendant classes by rewriting the code in a linear way, approximately like this:

  switch (field_type()) {

  case MYSQL_TYPE_TIME:

    // the code to process TIME

    return ...;

  case MYSQL_TYPE_DATE:

    // the code to process DATE

    return ...

  case MYSQL_TYPE_DATETIME:

    // the code to process DATETIME

    return ...;

  default:

    // the code to process non-temporal return type

    return ...;

  }

So later this switch(field_type) itself can be moved to Type_handler easy (under terms of a separate task).

The new code in the data-type specific blocks inside the switch will take advantage of the classes Time, Date and Datetime, which already have temporal type conversion functionality (such as TIME->DATETIME, DATETIME->TIME, DATE->DATETIME, DATETIME->DATE, etc).

The list of affected descendant classes:

• Item_date_add_interval
• Item_func_add_time
• Item_func_str_to_date

Note, only Item_date_add_interval::get_date() and Item_func_add_time::get_date() need to be rewritten, as Item_func_str_to_date::get_date() already returns the expected MYSQL_TIMESTAMP_XXX value.

During this refactoring, we'll make sure not to add too much duplicate code in the per-data-type code branches.