Fix: normalize datetime values to strings in unit tests

[georgesittas]

Fixes the issue discussed in this Slack thread: https://tobiko-data.slack.com/archives/C044BRE5W4S/p1749046530513469

[VaggelisD]

Don't really have a concrete comment, unless I'm downplaying the power of str(x), my hunch is this will cause false-negative comparisons again but I don't have a better solution at hand.

[VaggelisD]

Would the same output comparison work properly if we compared an equivalent datetime value from a different string? E.g `2024-01-02T15:00:00.00" or one based on a different timezone that results in the same time?

Ideally we'd normalize all datetime types into a common representation at a common timezone (?)

[georgesittas]

I think so, there's a test for this: https://github.com/TobikoData/sqlmesh/blob/f87d3f0a6dad639584a4b70540ac19010c0ca92c/tests/core/test_test.py#L1220

[VaggelisD]

This looks like it's on the same timezone from a quick look, I was referring to a scenario such as :

inputs:
   ...
   time_col: "2020-01-01 05:00:00+05"

outputs:
   ...
   time_col: "2020-01-01 00:00:00+00"

this test should be correct, right? But if it's a string comparison (or at best, normalized to a certain precision with zeroes) then it'd fail

[georgesittas]

I don't think that we encourage specifying time zones in the timestamp values (in the sense that it's unsupported).

The +zone syntax is only mentioned in relation to the execution_time variable in the docs, and I think that was intentional at the time.