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:

sqlmesh/tests/core/test_test.py

Line 1220 in f87d3f0

execution_time: "2023-01-01 12:05:03+00:00"

[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.