Clean Install with sqlserver - Error could not run provision

I am trying a clean installation of 2023.3 and I am using sqlserver.

The Corteza server almost immediately fails with an error message

corteza | could not start Corteza: could not run provision: store error: mssql: The conversion of a datetimeoffset data type to a datetime data type resulted in an out-of-range value.

It looks like the initial provision does manage to get some setup done as I can see 45 new tables created in the target sqlserver database.

What version of SQL server are you using?
When developing I tested it from 2017 (included) onwards

This is with SQL server 2022. I ran an SQL Server Profile trace on the activity and it is this statement that is causing the problem (I had to edit the @ parameters as the forum software thought I was mentioning multiple users.)

exec sp_executesql Nā€™UPDATE ā€œsettingsā€ SET ā€œupdated_atā€=@ p1,ā€œupdated_byā€=@ p2,ā€œvalueā€=@ p3 WHERE ((ā€œnameā€ = @ p4) AND (ā€œrel_ownerā€ = @ p5))ā€˜,Nā€™@ p1 datetimeoffset(7),@ p2 bigint,@ p3 varbinary(4),@p4 nvarchar(21),@p5 bigintā€™,@p1=ā€˜0001-01-01 00:00:00 +00:00ā€™,@ p2=0,@ p3=0x74727565,@ p4=Nā€™auth.external.enabledā€™,@ p5=0

From what I can tell the ā€˜0001-01-01ā€™ date is not accepted as a date time offset by SQL server.

When I looked at the same record as generated by provisioning on Postgres it has the identical parameter so I presume this is something thatā€™s identical within Corteza regardless of database type. If so and you did not see this issue I wonder if thereā€™s some sort of regional variation occurring?

For what it is worth I did check what the minimum datetime is for SQL server and itā€™s listed as 1st January 1753 SqlDateTime.MinValue Field (System.Data.SqlTypes) | Microsoft Learn

Trying the problem statement out as a stand alone SQL query does not generate any error so long as the datetime offset is at least 1753-01-01 00:00:00 but I suspect thatā€™s not the right solution.

The issue was that a timestamp in settings was not defaulted before provisioned; this should now be fixed and available when 2023.3.1 is released.

Thanks, I am guessing you donā€™t have an estimate on when that release will occur?