Generate the table name based on a required date filter with adjustments to the date filter values

There are a few posts based on this but not quite what I am looking for. I need to have the user enter a date filter…adjust that date filter to a specific grid for example 12:07 to 1:07 would become 12:00 to 1:00 and then based on the range determine the table to use. A minute granularity would go to the one minute table a one hour or greater would go to the hourly table. Do not ask the reason but the same field calculated in the hourly table has a different meaning than in the minute table.

I know I can adjust the filter value with SQL…but I am stuck on setting the proper table name. I do not want to use a parameter that specifies allowed values of minute hour day etc. but would rather have that calculated from the date filter entered.

Since sql_table_name does not accept SQL commands is there a liquid way I can get the actual date value for the filter start and then | to do a conversion so that I can do the same for the end date filter value and determine if it is greater than 60 minutes and set the table name string accordingly. I cannot seem to find a way to get the raw date filter value rather than SQL which is what you get when you do a {% date_start %}

I wonder if you could use the liquid remove/slice filters: to remove TIMESTAMP( from the {% date_start %} response and get something you can compare?

Also, you can use SQL in sql_table_name! It just has to be a subquery. like

view: theview {
sql_table_name: (SELECT * FROM x etc.);;

Although I guess that doesn’t fit the use case here of returning a string to literally use as the SQL table name.

I wnet down this path a bit only to realize that the format of the start and end date filter values are SQL and seem to be virtually impossible to liquid out a value that I can actually do a compare with when things like NOW() are possible and DATEADD with intervals etc. I was hoping for a way to get the actual date string but I can see how that might not be possible as it would require the SQL to be resolved.

I also thought about using | date: “%s” to get milliseconds since epoch and subtract from the end date filtered to milliseconds since epoch and checking to see if that is > the number of milliseconds in 60 minutes. Seems like it would be liquid hell if it is even possible.