Improved coverage of CONVERT date/time styles.

Author: RyanLamansky

SqlServerSimulator.Tests/ConvertTests.cs

@@ -221,6 +221,44 @@ public void Convert_DateTimeOffsetStyle127_ProjectsToUtcWithZ() =>
     public void Convert_StringToDateWithStyle(int style, string input) =>
         AreEqual(new DateTime(2026, 5, 13), ExecuteScalar($"select convert(date, '{input}', {style})"));
 
+    // General styles run SQL Server's flexible parser: separators (/ - .) are
+    // interchangeable and ISO year-first is accepted, with the trailing pair
+    // ordered by the style family. Each input below resolves to 2026-05-13.
+    [TestMethod]
+    [DataRow(101, "2026-05-13")]   // mdy + ISO year-first (the AdventureWorks shape)
+    [DataRow(101, "2026/05/13")]
+    [DataRow(101, "05-13-2026")]   // mdy, dash where the style documents slash
+    [DataRow(0, "2026-05-13")]     // default style, ISO
+    [DataRow(120, "2026-05-13")]   // ODBC canonical
+    [DataRow(102, "2026/05/13")]   // ymd, slash where the style documents dot
+    [DataRow(110, "05/13/2026")]   // mdy, slash where the style documents dash
+    public void Convert_StringToDate_GeneralStyle_SeparatorAndIsoFlexible(int style, string input) =>
+        AreEqual(new DateTime(2026, 5, 13), ExecuteScalar($"select convert(date, '{input}', {style})"));
+
+    [TestMethod]
+    [DataRow(103, "2003-04-05")]   // dmy + year-first → trailing pair is day-month → May 4
+    [DataRow(104, "2003.04.05")]
+    public void Convert_StringToDate_DmyYearFirst_OrdersTrailingDayMonth(int style, string input) =>
+        AreEqual(new DateTime(2003, 5, 4), ExecuteScalar($"select convert(date, '{input}', {style})"));
+
+    [TestMethod]
+    [DataRow("Apr 5 2003")]
+    [DataRow("April 5, 2003")]
+    [DataRow("5 Apr 2003")]
+    public void Convert_StringToDate_MonthNameForms_StyleIndependent(string input) =>
+        AreEqual(new DateTime(2003, 4, 5), ExecuteScalar($"select convert(date, '{input}', 101)"));
+
+    [TestMethod]
+    public void Convert_StringToDateTime_GeneralStyle_AmPmAndSpaceTime()
+    {
+        AreEqual(new DateTime(2003, 1, 1, 23, 59, 0), ExecuteScalar("select convert(datetime, 'Jan 1 2003 11:59PM', 101)"));
+        AreEqual(new DateTime(2003, 4, 5, 10, 20, 30), ExecuteScalar("select convert(datetime, '2003-04-05 10:20:30', 101)"));
+    }
+
+    [TestMethod]
+    public void Convert_StringToDateTime_GeneralStyle_BareTimeAnchorsTo1900() =>
+        AreEqual(new DateTime(1900, 1, 1, 10, 20, 30), ExecuteScalar("select convert(datetime, '10:20:30', 101)"));
+
     [TestMethod]
     public void Convert_StringToDateTime2_Style126() =>
         AreEqual(new DateTime(2026, 5, 13, 14, 25, 36, 789), ExecuteScalar(

SqlServerSimulator/Storage/SqlValue.Coerce.cs

@@ -434,78 +434,102 @@ internal SqlValue CoerceMoneyToStringWithStyle(SqlType target, int style)
     }
 
     /// <summary>
-    /// String → date-like coercion with a CONVERT style hint. Each style
-    /// pins the acceptable input format(s); a string that matches the
-    /// style's format parses; a string that's a valid date by some OTHER
-    /// format raises Msg 9807 (style mismatch); a string that's not a
-    /// valid date by any format raises Msg 241 (general parse failure).
-    /// Probe-confirmed against SQL Server 2025 (2026-05-13): all three
-    /// disposition paths land on the matching Msg numbers / wording.
+    /// String → date-like coercion with a CONVERT style hint, mirroring SQL
+    /// Server's flexible string-to-datetime parser (probed against SQL Server
+    /// 2025, 2026-05-27).
     /// </summary>
     /// <remarks>
-    /// Styles supported here: <c>1</c>/<c>101</c>, <c>10</c>/<c>110</c>,
-    /// <c>12</c>/<c>112</c>, <c>102</c>, <c>103</c>, <c>23</c>,
-    /// <c>126</c>/<c>127</c> (ISO 8601 with optional fractional seconds).
-    /// Other styles fall through to the default style-less parser via
-    /// caller dispatch.
+    /// <para>
+    /// <strong>Strict styles</strong> (<c>12</c> <c>yymmdd</c>, <c>112</c>
+    /// <c>yyyymmdd</c>, <c>23</c> <c>yyyy-mm-dd</c>, <c>126</c>/<c>127</c>
+    /// ISO 8601) pin an exact format; a string that's a valid date by some
+    /// OTHER format raises Msg 9807, a non-date raises Msg 241.
+    /// </para>
+    /// <para>
+    /// <strong>General styles</strong> route through .NET's flexible parser:
+    /// separators (<c>/ - .</c>) are interchangeable, and numeric / ISO
+    /// year-first / month-name forms plus an optional trailing time all parse.
+    /// The only family distinction is date-part order for ambiguous numeric
+    /// dates — the dmy set (<see cref="IsDayMonthYearStyle"/>) reads day-first
+    /// (<c>en-GB</c>), every other style month-first (<c>en-US</c>); a leading
+    /// 4-digit token is the year, with the trailing pair following the family
+    /// order. Known leniency divergences: the 2-digit-vs-4-digit-year
+    /// with/without-century restriction isn't enforced, and a <c>T</c>-separated
+    /// time is accepted under general styles (real SQL Server reserves it for
+    /// 126/127). See [`docs/claude/casting.md`].
+    /// </para>
     /// </remarks>
     internal SqlValue CoerceStringToDateLikeWithStyle(SqlType target, int style)
     {
         var input = this.AsString;
-        var formats = StyleSpecificDateFormats(style);
-        if (formats is null)
+
+        var strictFormats = StrictStyleDateFormats(style);
+        if (strictFormats is not null)
+        {
+            // AssumeUniversal + AdjustToUniversal keeps the wall-clock reading
+            // for style 127's `Z` UTC suffix regardless of host timezone.
+            const DateTimeStyles StrictParseStyles = DateTimeStyles.AllowWhiteSpaces | DateTimeStyles.AssumeUniversal | DateTimeStyles.AdjustToUniversal;
+            if (DateTime.TryParseExact(input, strictFormats, CultureInfo.InvariantCulture, StrictParseStyles, out var exact))
+                return FromDateTime2(SqlType.GetDateTime2(7), exact).CoerceTo(target);
+            if (DateTime.TryParse(input, CultureInfo.InvariantCulture, StrictParseStyles, out _))
+                throw SimulatedSqlException.InputCharacterStringStyleMismatch(style);
+            throw SimulatedSqlException.ConversionFailedDateTimeFromString();
+        }
+
+        var dayMonthYear = IsDayMonthYearStyle(style);
+        var culture = dayMonthYear ? GbCulture : UsCulture;
+        const DateTimeStyles ParseStyles = DateTimeStyles.AllowWhiteSpaces | DateTimeStyles.NoCurrentDateDefault;
+
+        // Separatorless yyyyMMdd is accepted under every general style but
+        // isn't recognized by the flexible parser.
+        if (DateTime.TryParseExact(input.Trim(), "yyyyMMdd", CultureInfo.InvariantCulture, DateTimeStyles.None, out var basic))
+            return FromDateTime2(SqlType.GetDateTime2(7), basic).CoerceTo(target);
+
+        // dmy + year-first: the flexible en-GB parse reads a leading 4-digit
+        // token then month-first, so force day-first on the trailing pair to
+        // match SQL Server (e.g. style 103 reads '2003-04-05' as 2003-05-04).
+        if (dayMonthYear
+            && DateTime.TryParseExact(input.Trim(), DayMonthYearFirstFormats, CultureInfo.InvariantCulture, ParseStyles, out var dmyYearFirst))
         {
-            // Style isn't in the parser's known set; fall back to default
-            // style-less parsing. Matches SQL Server's "silently ignore
-            // unrecognized style on string source" behavior for the styles
-            // that lack a dedicated input parser (e.g. styles only meaningful
-            // on output, like style 0 with mixed-type sources).
-            return this.CoerceTo(target);
+            return FromDateTime2(SqlType.GetDateTime2(7), dmyYearFirst).CoerceTo(target);
         }
-        // AssumeUniversal + AdjustToUniversal keeps the wall-clock reading
-        // when the input carries a `Z` suffix (style 127's UTC form): the
-        // parser would otherwise reinterpret `Z` as "convert to local
-        // timezone", which on a non-UTC host (e.g. Windows in PT) returns a
-        // value offset from the input. Real SQL Server's datetime2 target
-        // has no offset surface, so it preserves the literal wall-clock
-        // time verbatim — those flags get us the same result deterministically
-        // regardless of host timezone.
-        const DateTimeStyles ParseStyles = DateTimeStyles.AllowWhiteSpaces | DateTimeStyles.AssumeUniversal | DateTimeStyles.AdjustToUniversal;
-        if (DateTime.TryParseExact(input, formats, CultureInfo.InvariantCulture, ParseStyles, out var parsed))
+
+        if (DateTime.TryParse(input, culture, ParseStyles, out var parsed))
         {
-            // Re-encode via the simulator's own datetime2(7) path so target-
-            // specific narrowing (smalldatetime range, datetime2 precision,
-            // date-only truncation) goes through one route.
+            // A bare time (no date component) anchors to 1900-01-01 — NoCurrentDateDefault
+            // leaves the date at 0001-01-01, which is below the datetime range anyway.
+            if (parsed is { Year: 1, Month: 1, Day: 1 })
+                parsed = DateTimeSqlType.BaseDate.Add(parsed.TimeOfDay);
             return FromDateTime2(SqlType.GetDateTime2(7), parsed).CoerceTo(target);
         }
-        // Style didn't match. Distinguish "parseable as some date" (Msg 9807)
-        // from "not a date at all" (Msg 241) by trying the default parser.
         if (DateTime.TryParse(input, CultureInfo.InvariantCulture, ParseStyles, out _))
             throw SimulatedSqlException.InputCharacterStringStyleMismatch(style);
         throw SimulatedSqlException.ConversionFailedDateTimeFromString();
     }
 
+    private static readonly CultureInfo UsCulture = CultureInfo.GetCultureInfo("en-US");
+
+    private static readonly CultureInfo GbCulture = CultureInfo.GetCultureInfo("en-GB");
+
+    private static readonly string[] DayMonthYearFirstFormats = ["yyyy/d/M", "yyyy-d-M", "yyyy.d.M"];
+
     /// <summary>
-    /// Returns the input-format strings accepted by <see cref="CoerceStringToDateLikeWithStyle"/>
-    /// for the given style code, or <see langword="null"/> when the style
-    /// has no dedicated input parser (caller falls back to the default
-    /// style-less parser). Each style allows the trailing-time portion as
-    /// an optional extra: real SQL Server accepts <c>'20260513 14:25:36'</c>
-    /// under style 112 by parsing the date portion against style and the
-    /// time portion as free-form — the alternative formats here capture
-    /// that "date + optional time" shape.
+    /// The day-month-year CONVERT styles. Every other (general) style orders
+    /// ambiguous numeric dates month-first.
     /// </summary>
-    private static string[]? StyleSpecificDateFormats(int style) => style switch
+    private static bool IsDayMonthYearStyle(int style) =>
+        style is 3 or 4 or 5 or 13 or 14 or 103 or 104 or 105 or 113 or 114 or 130 or 131;
+
+    /// <summary>
+    /// Exact format(s) for the strict CONVERT styles (basic <c>yymmdd</c> /
+    /// <c>yyyymmdd</c> and the ISO 8601 forms, each with an optional trailing
+    /// time), or null for the general flexible styles.
+    /// </summary>
+    private static string[]? StrictStyleDateFormats(int style) => style switch
     {
-        1 => ["MM/dd/yy", "MM/dd/yy HH:mm:ss", "MM/dd/yy HH:mm:ss.fff"],
-        101 => ["MM/dd/yyyy", "MM/dd/yyyy HH:mm:ss", "MM/dd/yyyy HH:mm:ss.fff"],
-        10 => ["MM-dd-yy", "MM-dd-yy HH:mm:ss", "MM-dd-yy HH:mm:ss.fff"],
-        110 => ["MM-dd-yyyy", "MM-dd-yyyy HH:mm:ss", "MM-dd-yyyy HH:mm:ss.fff"],
         12 => ["yyMMdd", "yyMMdd HH:mm:ss", "yyMMdd HH:mm:ss.fff"],
-        112 => ["yyyyMMdd", "yyyyMMdd HH:mm:ss", "yyyyMMdd HH:mm:ss.fff"],
-        102 => ["yyyy.MM.dd", "yyyy.MM.dd HH:mm:ss", "yyyy.MM.dd HH:mm:ss.fff"],
-        103 => ["dd/MM/yyyy", "dd/MM/yyyy HH:mm:ss", "dd/MM/yyyy HH:mm:ss.fff"],
         23 => ["yyyy-MM-dd", "yyyy-MM-dd HH:mm:ss", "yyyy-MM-dd HH:mm:ss.fff", "yyyy-MM-dd HH:mm:ss.fffffff"],
+        112 => ["yyyyMMdd", "yyyyMMdd HH:mm:ss", "yyyyMMdd HH:mm:ss.fff"],
         126 or 127 =>
         [
             "yyyy-MM-ddTHH:mm:ss",

docs/claude/casting.md

@@ -81,7 +81,12 @@ Fractional-second separator follows the **source family**: legacy `datetime` / `
 
 **Time-only source hour-padding quirk**: styles 0/9/100/109 emit single-digit hour WITHOUT leading-space padding (`2:25PM`), but styles 22/130/131 DO pad (` 2:25:36 PM`) — verified against SQL Server 2025. The rationale isn't documented; the simulator mirrors it.
 
-**String → date-like** (`SqlValue.CoerceStringToDateLikeWithStyle`): style-aware parser hosts a list of `DateTime.TryParseExact` format strings per style. On parse success, re-encodes through `datetime2(7)` and narrows to the target. On parse failure: if the same input parses under the default style-less parser, raises **Msg 9807** (`"The input character string does not follow style N, …"`); otherwise raises **Msg 241** (`"Conversion failed when converting date and/or time from character string."`). `TRY_CONVERT` swallows both. Currently supports the same 1/10/12/23/101/102/103/110/112/126/127 input forms as the inverse direction; the wider style table from the output direction (styles 2/3/4/5/6/7/11/etc.) doesn't have input-direction parsers and falls through to default parsing — `CONVERT(date, '13.05.2024', 104)` parses via the default ISO parser instead of the German-style format. Minor pre-existing gap; expand on demand.
+**String → date-like** (`SqlValue.CoerceStringToDateLikeWithStyle`): mirrors SQL Server's flexible string-to-datetime parser (probed against SQL Server 2025, 2026-05-27). On success re-encodes through `datetime2(7)` and narrows to the target; on failure, an input that's a valid date by some other format raises **Msg 9807** (`"The input character string does not follow style N, …"`), a non-date raises **Msg 241**. `TRY_CONVERT` swallows both. Two style classes:
+
+- **Strict styles** — `12` (`yymmdd`), `112` (`yyyymmdd`), `23` (`yyyy-mm-dd`), `126`/`127` (ISO 8601 with `T`): exact `TryParseExact` format match, no separator flexibility. `CONVERT(date, '05/13/2026', 112)` → Msg 9807.
+- **General styles** (everything else) — route through `DateTime.TryParse` with a family culture. Separators (`/ - .`) are interchangeable; numeric, ISO year-first, and English month-name forms (`Apr 5 2003`, `April 5, 2003`, `5 Apr 2003`) plus optional trailing time / AM-PM / bare time (anchored to 1900-01-01) all parse. The **only** family distinction is date-part order for ambiguous numeric dates: the dmy set (`3`/`4`/`5`/`13`/`14`/`103`/`104`/`105`/`113`/`114`/`130`/`131` → `en-GB`) reads day-first, every other style (→ `en-US`) month-first. A leading 4-digit token is the year, trailing pair in family order — so `2003-04-05` is Apr-5 under style 101 but May-4 under 103 (a 3-format `yyyy{sep}d{sep}M` pre-check supplies the dmy year-first ordering `TryParse` won't). Separatorless `yyyyMMdd` is accepted under every general style.
+
+**Known leniency divergences** (simulator accepts more than the live server, low-value edges): the 2-digit-vs-4-digit-year with/without-century restriction isn't enforced (`CONVERT(datetime, '04/05/03', 101)` succeeds; live rejects), and a `T`-separated time is accepted under general styles (live reserves `T` for 126/127, raising out-of-range otherwise).
 
 **Money → string** (`SqlValue.CoerceMoneyToStringWithStyle`):
 

docs/claude/xml.md

@@ -58,7 +58,7 @@ Backs `.value()` / `.nodes()` / `.query()` / `.exist()`. Covers the subset SQL S
 ### Divergences
 
 - Only the path subset above is modeled. FLWOR, arithmetic / comparison / boolean XQuery operators, `local-name()`-style functions in the source text, and constructors are not — they'd surface as malformed XPath or wrong results rather than a clean error.
-- `.value()` casts go through the standard string→type coercion, which inherits the simulator's CONVERT limitations — notably **`CONVERT(datetime, '<yyyy-mm-dd>', 101)` rejects year-first ISO strings the live server accepts under mdy-family styles** (Msg 9807). This blocks the AdventureWorks `vJobCandidateEducation` / `vJobCandidateEmployment` / `vPersonDemographics` views at the downstream `CONVERT`, not at the XML extraction. Tracked as a CONVERT date-style gap, separate from XML.
+- `.value()` casts go through the standard string→type coercion (`casting.md`'s flexible string→date-like parser), so the AdventureWorks `vJobCandidateEducation` / `vJobCandidateEmployment` / `vPersonDemographics` views — which wrap `.value()` date strings in `CONVERT(datetime, …, 101)` — now resolve.
 
 ## Catalog views in `BuiltInResources.cs`