Fix!: Support full precision for TSQL date types

[themisvaltinos]

This update aims to enhance the support for MSSQL/T-SQL full precision when building the end_dt macro and date ranges, specifically for date types with up to 100 nano seconds precision, fixes: #3624

[tobymao]

is this type still right is datetime and pd.Timedelta a subclass?

[georgesittas]

yep, for example:

>>> pd.Timestamp("2020-01-01") + pd.Timedelta(1, unit="day")
Timestamp('2020-01-02 00:00:00')
>>> issubclass(pd.Timestamp, datetime.datetime)
True

[tobymao]

does time delta no longer work?

[themisvaltinos]

good point, adding a one day timedelta works here so no need for pandas in this

[tobymao]

do we need a migration for this? cc @georgesittas

[georgesittas]

do we need a migration for this? cc @georgesittas

There's definitely a diff between main and this PR. E.g. if I change the filter in the example incremental model to:

-- instead of `@start_date` and `@end_date`
event_date BETWEEN @start_dt AND @end_dt

Then I see this after running first plan, switching to this branch, wiping out cache and re-running plan:

Models:
├── Directly Modified:
│   └── sqlmesh_example.incremental_model
└── Indirectly Modified:
    └── sqlmesh_example.full_model

Directly Modified: sqlmesh_example.incremental_model (Non-breaking)
└── Indirectly Modified Children:
    └── sqlmesh_example.full_model (Indirect Non-breaking)
Models needing backfill (missing dates):
└── sqlmesh_example.incremental_model: 2020-01-01 - 2025-01-21

I think an empty migration script should do the trick here.