ASP.NET Core 8 Web API迁移后DateTime格式化引发SQL转换错误

核心问题 #

服务器上的文化设置虽然和本地显示一致，但实际的月份缩写格式（比如Jun. vs Jun）存在差异，导致生成的日期字符串不符合SQL Server的datetime转换要求。由于你没有显式配置应用的文化，ASP.NET Core会默认使用服务器系统的当前文化，而这个文化的月份缩写规则和本地不一致。

配置Program.cs统一文化格式 #

你可以在Program.cs中全局配置应用的默认文化，强制使用月份缩写不带点的文化（比如en-US），这样所有DateTime.ToString("d MMM yyyy")的调用都会统一生成不带点的格式：

var builder = WebApplication.CreateBuilder(args);

// 配置全局请求本地化，指定默认文化
builder.Services.Configure<RequestLocalizationOptions>(options =>
{
    var targetCulture = "en-US"; // 根据你的业务需求选择合适的文化
    var cultureInfo = new CultureInfo(targetCulture);
    
    options.DefaultRequestCulture = new RequestCulture(cultureInfo);
    options.SupportedCultures = new List<CultureInfo> { cultureInfo };
    options.SupportedUICultures = new List<CultureInfo> { cultureInfo };
});

// 其他服务注册（比如AddControllers等）...

var app = builder.Build();

// 启用本地化中间件，必须放在路由相关中间件之前
app.UseRequestLocalization();

// 其他中间件配置（比如UseAuthorization、MapControllers等）...

app.Run();

如果你的业务需要支持多文化，但特定场景下需要统一日期格式，也可以单独为DateTime设置自定义格式化规则，但全局统一文化的方式更简洁，能避免其他地方出现类似的格式问题。

额外建议（根本解决） #

尽量不要将DateTime转换为字符串拼接SQL语句，改用参数化查询（比如Entity Framework Core的LINQ查询，或者SqlCommand的参数）。这样不仅能彻底避免日期格式转换问题，还能防止SQL注入，是更安全、更规范的做法。比如：

// 示例：用参数化查询替代字符串拼接
using var command = new SqlCommand("SELECT * FROM Orders WHERE OrderDate >= @StartDate", connection);
command.Parameters.AddWithValue("@StartDate", DateTime.Today.AddMinutes(1));

内容的提问来源于stack exchange，提问作者Ross Kelly