Summary "by hour of day" sometimes includes the current day date in the hour groupings

[notrom]

Describe the bug
Aggregate and grouping "by hour of day" will sometimes include the current days date in the groupings. This seems to depend on the Metabase Data Model type setting for that datetime field.

If you've selected "No special type" in the data model for that datetime then you get the current date in the groupings. If you select any of the available "Date and Time" types then it works correctly and only gives the hour in the groupings.

Logs
When I see this error (dates in the hour of day I don't get anything in the javascript console.

When I group by hour of day and don't see this issue I get this in the javascript console each time I refresh:

Unknown date style 
t.getDateFormatFromStyle | @ | app-main.bundle.js?d…7e3bb361b4e3fcba5:5
K  @  app-main.bundle.js?d…7e3bb361b4e3fcba5:5
...

To Reproduce
Steps to reproduce the behavior:

1. In data model set Sample Date > Orders > Created At field to "Creation timestamp"
2. New Question, Orders, Count grouped by Created At hour of day
3. Note the hour groupings are displayed correctly, only includes the hour i.e. "1:00"
4. Change the type of that field to "No special type"
5. Refresh question
6. Note that the groupings now include the current days date i.e. "December 18, 2020, 1:00 AM"

Expected behavior
The date should not be displayed in the groupings.

Screenshots
As a Date and Time type, all looks ok (not so sure about that 24:00 though?)

As a "No special type" the error is presented

Information about your Metabase Installation:

{
  "browser-info": {
    "language": "en-NZ",
    "platform": "Win32",
    "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.198 Safari/537.36",
    "vendor": "Google Inc."
  },
  "system-info": {
    "file.encoding": "Cp1252",
    "java.runtime.name": "Java(TM) SE Runtime Environment",
    "java.runtime.version": "1.8.0_161-b12",
    "java.vendor": "Oracle Corporation",
    "java.vendor.url": "http://java.oracle.com/",
    "java.version": "1.8.0_161",
    "java.vm.name": "Java HotSpot(TM) Client VM",
    "java.vm.version": "25.161-b12",
    "os.name": "Windows Server 2012 R2",
    "os.version": "6.3",
    "user.language": "en",
    "user.timezone": "Pacific/Auckland"
  },
  "metabase-info": {
    "databases": [
      "sqlserver",
      "postgres",
      "h2"
    ],
    "hosting-env": "unknown",
    "application-database": "postgres",
    "application-database-details": {
      "database": {
        "name": "PostgreSQL",
        "version": "10.5"
      },
      "jdbc-driver": {
        "name": "PostgreSQL JDBC Driver",
        "version": "42.2.8"
      }
    },
    "run-mode": "prod",
    "version": {
      "tag": "v0.37.2",
      "date": "2020-11-16",
      "branch": "release-x.37.x",
      "hash": "25e5f70"
    },
    "settings": {
      "report-timezone": "Pacific/Auckland"
    }
  }
}

Severity
Frustrating, confusing, and inconsistent. Users don't understand why they're seeing a date part when they asked for hours of the day. Not the end of the world but it doesn't just work out of the box.

I couldn't find a way around this via formatting the output, the only way was to change the type in the data model which most users cannot do.

Additional context
Part of the problem may be that there is not a "Date and time" type in the Metabase data model for general datetimes. For instance we have many datetimes that are the time of an "event". It's not a start, join, create, cancelation, delete so it doesn't fit any of those narrow categories. But I do want to be able to do things like group by hour of day.

If either there was a default datetime type available, or "No special type" fields that happen to be datetimes get treated the same as the specific types that would probably be sufficient.

[flamber]

Hi @notrom
You can use any of the time types. They will only have a difference on X-rays, but from a formatting point they are the same.
There's a proposal on redoing the types, so it's split and will allow for more generic selection #14054
And 24:00 is this issue #9538 - related #11398

[flamber]

Fixed in 0.39.0, but still shows AM/PM for 24h setting set globally, which is likely the same problem as #11398