Humanizr/Humanizer · error · InvalidOperationException

Unsupported default ordinal-date converter '{converterTypeNa

Error message

Unsupported default ordinal-date converter '{converterTypeName}'.

What it means

Thrown during source generation by CreateConverterExpression when an ordinal-date profile uses engine 'default', but the converter type name passed to the generator does not match either of the two supported types (PatternDateToOrdinalWordsConverter or PatternDateOnlyToOrdinalWordsConverter). This is an internal generator wiring error, not a user YAML error.

Source

Thrown at src/Humanizer.SourceGenerators/Generators/ProfileCatalogs/OrdinalDateProfileCatalogInput.cs:176

            builder.AppendLine("}");

            if (!string.IsNullOrWhiteSpace(condition))
            {
                builder.AppendLine();
                builder.AppendLine("#endif");
            }

            context.AddSource(sourceName, SourceText.From(builder.ToString(), Encoding.UTF8));
        }

        static string CreateConverterExpression(OrdinalDateProfileDefinition profile, string converterTypeName) =>
            profile.Engine switch
            {
                "default" => converterTypeName switch
                {
                    "PatternDateToOrdinalWordsConverter" => "new DefaultDateToOrdinalWordConverter()",
                    "PatternDateOnlyToOrdinalWordsConverter" => "new DefaultDateOnlyToOrdinalWordConverter()",
                    _ => throw new InvalidOperationException($"Unsupported default ordinal-date converter '{converterTypeName}'.")
                },
                "pattern" => CreatePatternExpression(profile, converterTypeName),
                _ => throw new InvalidOperationException($"Unsupported ordinal date engine '{profile.Engine}'.")
            };

        static string CreatePatternExpression(OrdinalDateProfileDefinition profile, string converterTypeName)
        {
            var pattern = GetRequiredString(profile.Root, "pattern");
            var hasGregorianMonths = profile.Months.Length > 0;
            var hasHijriMonths = profile.HijriMonths.Length > 0;
            var hasAnyMonthOverride = hasGregorianMonths || hasHijriMonths;

            if (hasAnyMonthOverride && ContainsAbbreviatedMonth(pattern))
            {
                throw new InvalidOperationException(
                    $"Ordinal date profile '{profile.ProfileName}' uses MMM (abbreviated month) " +
                    "which is not supported when calendar month overrides are active. " +
                    "Only MMMM (full month name) substitution is supported.");

View on GitHub (pinned to ffc2b77c0f)

Solutions

Check the EmitDateCatalog call that produced the error and verify its converterTypeName argument matches one of the two known values.
If a new converter type was added, add a new case arm mapping it to the correct constructor expression in the switch at OrdinalDateProfileCatalogInput.cs:172.
Ensure the engine value in the locale YAML is correctly set to 'default' only when one of the two supported converter types applies.

Example fix

// before — a third converter type is passed but not handled
"default" => converterTypeName switch
{
    "PatternDateToOrdinalWordsConverter" => "new DefaultDateToOrdinalWordConverter()",
    "PatternDateOnlyToOrdinalWordsConverter" => "new DefaultDateOnlyToOrdinalWordConverter()",
    _ => throw ...
},

// after — add the new case
"default" => converterTypeName switch
{
    "PatternDateToOrdinalWordsConverter" => "new DefaultDateToOrdinalWordConverter()",
    "PatternDateOnlyToOrdinalWordsConverter" => "new DefaultDateOnlyToOrdinalWordConverter()",
    "PatternCustomDateToOrdinalWordsConverter" => "new CustomDateToOrdinalWordConverter()",
    _ => throw ...
},

Defensive patterns

Strategy: validation

Validate before calling

// This is an internal generator error. Prevent it by ensuring that any
// converterTypeName passed to EmitDateCatalog matches one of the two
// supported values. If adding a new converter type, add its case to the
// switch in CreateConverterExpression at OrdinalDateProfileCatalogInput.cs:172.

Prevention

When adding a new ordinal-date converter type, add its case arm to CreateConverterExpression immediately.
Review all EmitDateCatalog call sites when changing converter type names.
Keep this file's switch arms synchronized with the catalog class names.

When it happens

Trigger: The generator internally maps a locale's ordinal-date feature to a converter type name and then dispatches on it. If the converter type name is misspelled or newly introduced without updating this switch, the default arm fires. This would typically only happen during active development of the generator or locale infrastructure.

Common situations: A Humanizer developer adds a new ordinal-date converter type but forgets to add its case to the switch in CreateConverterExpression. Or the EmitDateCatalog method is called with a new converterTypeName argument that is not in the supported set.

Related errors

AI-assisted analysis of Humanizr/Humanizer@ffc2b77c0f (2026-08-13). Data as JSON: /api/errors/654a2562765a2744. Report an issue: GitHub.