mirror of
https://github.com/go-gitea/gitea.git
synced 2026-06-26 06:47:20 +02:00
c2f130d352
## Problem On MSSQL databases created by old Gitea versions, the real datetime columns `external_login_user.expires_at` and `lfs_lock.created` were created as `DATETIME`. `DATETIME` parses datetime literals in a locale-dependent way, so the ISO string `'YYYY-MM-DD HH:MM:SS'` that xorm sends fails to convert when the session language is not English (e.g. German defaults to `dmy`): ``` mssql: Bei der Konvertierung eines nvarchar-Datentyps in einen datetime-Datentyp liegt der Wert außerhalb des gültigen Bereichs. ``` This breaks linking an external (OAuth/Keycloak) account to an existing user, and LFS lock creation, with a 500 error. ## Fix Current xorm already maps `time.Time` to the locale-independent `DATETIME2` for new installs, so only legacy databases are affected. This adds migration `341` that converts these columns to `DATETIME2` on legacy MSSQL databases (no-op on other databases and on columns already using `DATETIME2`). A full audit of persisted `time.Time` columns in `models/` confirmed these two are the only real datetime columns affected — every other time value is stored as a unix-timestamp integer. A regression test (MSSQL-only, mirroring the existing v338 pattern) downgrades the columns to legacy `DATETIME`, runs the migration, asserts the type becomes `DATETIME2`, and verifies an ISO datetime insert succeeds under `SET LANGUAGE German`. Fixes #38211