Convert.ChangeType does not work with DateOnly

[MgSam]

Description

System.Convert.ChangeType does not work converting System.String to System.DateOnly. I would expect it to work given that it does work for System.String to System.DateTime.

Reproduction Steps

Convert.ChangeType("1/1/2000", typeof(DateTime)); //Works
Convert.ChangeType("1/1/2000", typeof(DateOnly)); //InvalidCastException

Expected behavior

System.Convert.ChangeType should work for String -> DateOnly

Actual behavior

System.Convert.ChangeType does not work for String -> DateOnly

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

Tagging subscribers to this area: @dotnet/area-system-runtime
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

System.Convert.ChangeType does not work converting System.String to System.DateOnly. I would expect it to work given that it does work for System.String to System.DateTime.

Reproduction Steps

Convert.ChangeType("1/1/2000", typeof(DateTime)); //Works
Convert.ChangeType("1/1/2000", typeof(DateOnly)); //InvalidCastException

Expected behavior

System.Convert.ChangeType should work for String -> DateOnly

Actual behavior

System.Convert.ChangeType does not work for String -> DateOnly

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

Author:	MgSam
Assignees:	-
Labels:	area-System.Runtime, untriaged
Milestone:	-

[MichalPetryka]

Convert.ChangeType is a legacy API that generally shouldn't be used and this is caused by DateOnly not being in the TypeCode enum.

[MgSam]

Convert.ChangeType is a legacy API that generally shouldn't be used and this is caused by DateOnly not being in the TypeCode enum.

Why is it "legacy"? And what is the replacement? Why not put DateOnly into TypeCode?

[tannergooding]

Convert is slow, not type safe, is lacking quite a bit of "key" functionality, and is not easily extensible to new types as much of it functions on or around TypeCode.

For converting between number types, .NET 7 exposes the INumberBase<T>.CreateChecked, CreateSaturating, and CreateTruncating APIs.

For converting between a string and a type, you have the IParsable (.NET 7) and IFormattable (.NET 1.0) APIs.

When you directly know the types you're converting between, using the concrete type is almost always a better option (DateOnly.Parse in this case). When you're working with unknown types, the new interfaces in .NET 7 provide a fast, safe, and extensible way to expose the functionality to developers.

[MgSam]

Convert is slow, not type safe, is lacking quite a bit of "key" functionality, and is not easily extensible to new types as much of it functions on or around TypeCode.

I agree it's not type safe. That's kind of the whole point of the API :) The types are only known at runtime. Yes, it's slower but that's a price you sometimes have to pay when you're working with purely dynamic data.

I disagree that it's not extensible. I looked at the implementation and it looks at whether the type is IConvertible. DateOnly is not IConvertible for whatever reason. You don't actually even need the DateOnly in the TypeCode enum for it to work here.

For converting between number types, .NET 7 exposes the INumberBase<T>.CreateChecked, CreateSaturating, and CreateTruncating APIs.

For converting between a string and a type, you have the IParsable (.NET 7) and IFormattable (.NET 1.0) APIs.

When you directly know the types you're converting between, using the concrete type is almost always a better option (DateOnly.Parse in this case). When you're working with unknown types, the new interfaces in .NET 7 provide a fast, safe, and extensible way to expose the functionality to developers.

I'm still not clear how any of that is equivalent to converting from one Type to another Type, where both types are only known at runtime. Seems like you're assuming we always want to convert from strings, which is definitely not the case.

In short, I think this API exists for a reason, and unless you guys offer a real replacement for converting from Type to Type, I think it should continue to work for the new "primitive" types being added (like DateOnly). If you guys want to to not use IConvertible or TypeCode, I think that's an implementation detail- but the need for this particular API is as real today as when it was created 20 years ago.

[tannergooding]

In short, I think this API exists for a reason, and unless you guys offer a real replacement for converting from Type to Type, I think it should continue to work for the new "primitive" types being added (like DateOnly)

It is not the responsibility of the BCL to provide "everything" and it is impossible for us to do so. It is just as much the responsibility of consumers to fill the gap where they have needs by introducing their own wrappers or additional functionality where required.

We do provide APIs where they are warranted and where they have a concrete need. This is not one of those cases and is likely the type of API we would not expose or would expose significantly differently if the framework were redesigned from scratch (without backcompat concerns).

IConvertible and the Convert class both have real limitations and high back-compat concerns. There are a plethora of "core" types that don't support (including types that were in .NET 1.0) and the interface/enum hasn't been versioned for any of them. DateOnly and TimeOnly are no exception here and so just like you would have to do with Half, Int128, UInt128, Guid, TimeSpan, nullables, or any of the other "core" types you will need to fill the gap here yourself.

DateOnly is not IConvertible for whatever reason

It is not IConvertible because IConvertible is not extensible. The interface is designed around TypeCode which is very limited and basically only supports the "core" types that VB and C# had as "primitives" in .NET 1.0. Modifying the TypeCode enum has a very high risk of breaking existing "core" code for third party libraries and additionally requires that the supported types exist in S.P.Corelib itself.

In particular the existing DateTime is only convertible to itself, string, and object. Every other IConvertible and Convert.* API throws for DateTime. If you need/have an object, then casting to object directly is better. It will be a nop if you already have a reference type and a box/unbox otherwise. If you need/have a string, then the format/parse APIs are better.

[MgSam]

I agree, the TypeCode enum and IConvertible have limitations. So make an implementation that doesn't use them. The signature is Convert.ChangeType(object value, Type conversionType). There is nothing about that signature that implies nor requires any particular implementation. It could just as easily do something entirely different using is.

In particular the existing DateTime is only convertible to itself, string, and object. Every other IConvertible and Convert.* API throws for DateTime. If you need/have an object, then casting to object directly is better. It will be a nop if you already have a reference type and a box/unbox otherwise. If you need/have a string, then the format/parse APIs are better.

I think you're misunderstanding a lot of the usage of these APIs. They usually go hand-in-hand with ADO.NET and its successors. Dynamically reading/writing data from a database what could be any primitive type and need to get converted to other primitive types on its journey back and forth (where such conversions make sense). No one is expecting it to miraculously convert DateOnly into a double somehow.

I don't think asking Microsoft to make BCL methods that already exist add support for new "primitive" types that Microsoft is now shipping to be particularly onerous or unfair. Obviously you cannot ship baked-in support for 3rd party types you don't know about.

More broadly, I think your team should be more cautious about "deprecating" APIs that are still shipping and still in heavy use without having any clear replacement. (DataTable comes to mind as another obvious example. The team refuses to improve it- yet there is no real alternative- the DataFrame project has been more-or-less abandoned.)

[tannergooding]

My point remains that there are two scenarios that IConvertible supports:

1. Conversion to/from string
2. Conversion between primitive number types

For 1, the parsing and formatting APIs are better. For 2, the new number create APIs are better. Both of these approaches also work well with trimming, AOT, and scenarios where reflection is limited or unavailable.

If you wanted to support a generic conversion API using a truly arbitrary object and Type, you have the option of writing a small reflection based wrapper that invokes the relevant IParsable<T>.Parse or INumberBase<T>.Create* APIs. This will end up being, especially with caching of the resolve MethodInfo, faster and will support more conversion scenarios.

[TomaszWegrzyn]

Convert.ChangeType is a legacy API that generally shouldn't be used and this is caused by DateOnly not being in the TypeCode enum.

This is kind of a sidenote, but I would prefer to find this information in docs instead random comment on github
Wish my team had known this earlier, before we started using it.