Datetime column in MSSQL migrations

In knex.schema, creating or altering a column using table.dateTime() or table.timestamp() generates a query that uses the datetime type. Microsoft discourages the use of this type for new work and recommends using datetime2 instead, since it’s got considerably better precision, a wider representable range and is ANSI SQL compliant, without using any more storage (both types are 8 bytes wide by default). datetime2 is available since SQL Server 2008, but since I believe other parts of knex generates syntax requiring at least SQL Server 2012, that shouldn’t be a problem. The dominant MSSQL Node driver (Tedious) supports both and returns both as a Javascript Date by default.

Now, this is trivial to work around with table.specificType, but I think knex should default to the recommended best practice. I am willing to create a PR for this, but before I do that I figured I’d check if there are any potential problems I’ve overlooked with such a change. I don’t know what the policy is on backwards compatibility in migrations, either.

In addition to switching to datetime2, MSSQL also has a timezone-aware type, datetimeoffset, which is like datetime2 but including a timezone offset (in Postgres terms it’s a timestamptz). Perhaps a better idea would be to implement the same API as Postgres, that is table.dateTime(columnName, withoutTimezone), but unlike just switching from datetime to datetime2 which is technically incompatible but unlikely to actually break things in practice, changing to timezone-aware by default has a great deal of potential for interesting bugs.

[dhensby]

fixed in #2757

[kblomster]

That sounds reasonable. I’ll take a look at setting up a PR.