Promote System.Time to corefx?

[mattjohnsonpint]

As discussed in aspnet/Mvc#6648, the types in the System.Time package would be useful in providing support in MVC tag helpers for <input type="date" /> and <input type="time" /> which are in the HTML5 spec.

I see only one open issue, #300, which is a feature request. Other than this, what are the steps necessary to promote System.Time to corefx and make it available on nuget.org?

[mattjohnsonpint]

@tarekgh @dougbu

[dougbu]

/cc @DamianEdwards

[mattjohnsonpint]

Also, when we originally discussed this proposal back in 2015 (see dotnet/corefx#2116), it seemed that a System.Time nuget package was the appropriate course of action. But now here we are two years later, and the world has changed a bit. It seems that it may be more appropriate for this to land in the System.Runtime package, which is where DateTime, DateTimeOffset, TimeSpan and TimeZoneInfo reside.

If there's no objection, I'll move this forward by pitching an API proposal on the corefx repo.

In other words, I don't see why this should be any different than other proposals for date/time such as dotnet/corefx#24555 and dotnet/corefx#24449.

[mattjohnsonpint]

We should also get consensus on #1870 before doing so, if possible.

[drieseng]

Some questions/remarks:

System.Date

• Why are there no addition and subtraction operators (but instead we have MonthsSince(Date), MonthsUntil(Date), DaysUntil(Date), ...)?
• Why is there no support for the optional timezone designator in xs:date?
• Will WCF (client and eventually server) be updated to support mapping xs:date to System.Date (and vice versa)?

System.TimeOfDay

• Why have both operators and Add/Subtract methods for TimeSpan?
• Why is there no support for the optional timezone designator in xs:time?
• Will WCF (client and eventually server) be updated to support mapping xs:time to System.TimeOfDay (and vice versa)?

[mattjohnsonpint]

@drieseng - great questions. Thanks!

There are no addition/subtraction operators between two Date objects because adding two Dates would be a meaningless operation, and subtracting two dates would require a type capable of holding years, months, and days as separate units, such as Period in the Noda Time library. We would have to expand the scope of this to include such a type.

It would be possible to have Date + TimeOfDay = DateTime (unspecified Kind), but that is more of a conjunction of bringing two types together to form a third than true addition. It is better served with the At method. Date - TimeOfDay is another meaningless operation.

TimeOfDay has both operators and Add/Subtract methods, because both are meaningful operations and they follow a precedent set by the TimeSpan and DateTime structs. (Keep in mind that these new types are meant to complement the existing ones.)

Regarding the optional time zone designator in xs:date and xs:time - I have found little value in having offsets on these types. Especially for a date-only type - how is an offset useful? If anything, it's problematic, as the offset could change sometime during the day. XSD has had to write in some clarifying points that in that edge case they consider the offset to apply to the first moment of the day, but that logic is breaking single-responsibility-principle. A date-only type should be such that it applies to any moment on the date, or rather to the entire date. One can only rationalize about offsets when talking about time. Indeed, ISO-8601 does not permit a date+offset partial value either.

For xs:time, there is some precedented support for a time+offset with both ISO-8601 and Java 8's OffsetTime type, as well as in the ANSI SQL standard and database that try to conform to it. But still, it has questionable usefulness because in so many time zones the offset changes throughout the year. One needs both date and time before an offset is very meaningful. Consider that (for example) the PostgeSQL docs define time with time zone but go out of their way to discourage its use.

A better alignment than XSD would be HTML5, whose <input type="date"/> and <input type="time" /> do not allow for offsets.

Also, keep in mind that I am not trying to introduce an entirely new date/time approach in .NET. That already exists in the Noda Time library. Instead, I am trying to simply fill in some much-needed gaps. Date-only data is everywhere (birthdays, business days, holidays, etc.), and so is time-only data (business hours, school hours, recurring appointments, etc.). Having these types built-in solves a real-world need.

With regard to WCF - I can't speak specifically to that. However, I'll say that there are many uses for these types throughout the .NET ecosystem. In some cases, teams have had to develop their own pseudo-types, such as Edm.Date and Edm.Time, and their corresponding pseudo-types in OData - which lead to strange workarounds like those described here. Hopefully with these types built-in, we can avoid such pain in the future.

[benaadams]

@mj1856 agree with everything except

subtracting two dates would require a type capable of holding years, months, and days as separate units,

It would return a TimeSpan where the maximal unit is days. Though isn't really a huge issue.

[drieseng]

@mj1856 Thanks for taking time to respond to my questions!

There are no addition/subtraction operators between two Date objects because adding two Dates would be a meaningless operation, and subtracting two dates would require a type capable of holding years, months, and days as separate units, such as Period in the Noda Time library. We would have to expand the scope of this to include such a type.

Adding two dates is indeed meaningsless.
I was thinking of the following for addition:

public static DateTime operator +(Date d, TimeSpan t) { ... }
public static DateTime operator +(Date d, TimeOfDay t) { ... }

However I agree that the individual Add methods are also useful, since they allow you to avoid going through DateTime to arrive at another Date instance.

As @benaadams already mentioned, for subtraction one could indeed define the following operator:

public static TimeSpan operator -(Date d1, Date d2) { ... }

With regard to WCF - I can't speak specifically to that. However, I'll say that there are many uses for these types throughout the .NET ecosystem. In some cases, teams have had to develop their own pseudo-types, such as Edm.Date and Edm.Time, and their corresponding pseudo-types in OData - which lead to strange workarounds like those described here. Hopefully with these types built-in, we can avoid such pain in the future.

Wouldn't it be a good idea to have the WCF and EF (and other) teams chime in on this. It would be a pity if these types finally arrived in .NET, only to ascertain that this had zero impact on the problems that these could solve.

[mattjohnsonpint]

@benaadams - Subtracting two Dates to get a TimeSpan would be problematic. TimeSpan has a resolution down to 100ns ticks. Its concept of "days" are a fixed 24-hours (exactly) of time. However, when working with dates, a "day" is not a fixed unit of time. Some days have more or less than 24 hours depending on how they are evaluated.

For example, this coming Sunday is 2017-10-29. When evaluated in the US it has 24 hours. When evaluated in most of Europe (and other places), it has 23 hours - because this is the day that the clocks go from daylight time back to standard time.

In other words, don't conceptualize dates as some aggregate unit of time. Instead. think of dates as you would a square on a paper 12-month calendar. It is an abstract concept, that doesn't have time or time zone.

[mattjohnsonpint]

@drieseng - Always glad to participate in a discussion about dates and times! 👍

Of the two operators you suggested, it would be possible to include the second one, though it is essentially a shortcut for the At method that is already included. My point was that it is not true "addition", so it may create confusion. Consider that DateTime + TimeSpan == DateTime exists already, but in that case one is truly adding an elapsed duration of time (not a time-of-day) to something that often represents a specific point in time already (DST and other transitions aside). So I don't think it's quite in alignment to have the + operator mean "addition" in one scenario and "combination" in another scenario, for types that are so closely related.

The first one you suggested would not be valid. A Date is intended to represent a whole date - not a specific point in time on that date. A TimeSpan is primarily an elapsed duration of time. Ask yourself in English: "What is today plus 3 seconds?" and hopefully you can see how that is an ambiguous question.

Regarding integration with other teams - the need is already established, but it will take having these types ubiquitous before it will be possible to facilitate those discussions beyond what I've already been able to do (both here on GitHub, and internally).

The general issue is that while everyone agrees that .NET's date/time handling is less-than-ideal, it's not quite bad enough to resist continuing with the workarounds we've had since the beginning (such as using DateTime at 00:00 for dates, using TimeSpan for time-of-day, and other mismatches and hacks). Contrast that with (for example) Java, whose internal date and time (java.util.Date, java.util.Calendar, etc.) have been so bad for so long that it pushed the majority of the Java community over to external libraries (Joda-Time, Time4J, etc.), before things could swing back around to become the java.time native package in Java 8. Though we have benefited from their pain by having awesome libraries like Noda Time emerge, our community never quite reached the quorum that the Java community did to push for a complete overhaul.

Thus, with these new bits I'm proposing - I'm not looking to solve the world for everyone, but rather to pick off the lowest hanging fruit. These are the things that have the widest impact for those who are not looking to convert everything over to Noda Time, but still want to model their data more cleanly, and interact better with external APIs.

[benaadams]

Fair enough, subtraction may be ambiguous and it does have the DaysUntil and DaysSince apis which are specific for this scenario.

[mattjohnsonpint]

Yep. I chose DaysUntil/DaysSince, MonthsUntil/MonthsSince and YearsUntil/YearsSince APIs as an alternative for having a Period-like structure as a result of subtraction operations.

[YohDeadfall]

@drieseng It's not a problem to add TimeOfDay and Date support to DataContractSerializer which is used by WCF. I can do that if it's assigned to me.

But what's about landing? I agree with @mj1856 that the System.Runtime package is the best place for these types. It's better to have all time types in a single library since they will be widely used in the correct way. Date for dates instead of DateTime with zeroed time, Time for time instead of TimeSpan.

[drieseng]

@YohDeadfall I'm sure there's a lot more to it than that. For example, the SOAP importer and exporter should be updated to support exposing Date and TimeOfDay as xs:date and xs:time, and should deserializing xs:date and xs:time as Date and TimeOfDay.

[YohDeadfall]

@drieseng, which could be done by data contracts, XmlWriter and XmlConvert. Take a look at DateTime serialization in the System.Private.DataContractSerializer project from the CoreFx repository.

[drieseng]

@YohDeadfall Is it feasible to update WCF server (.NET Framework) as well?

[mconnew]

Regarding the optional time zone designator in xs:date and xs:time - I have found little value in having offsets on these types.

@mj1856 If this is intended to be used as the data type for xs:time, you need to think about being able to round trip data. Although you have found little value in the offset, someone has and are using it in xml documents. If there is no offset in the .Net data type, it isn't a match for xs:time and shouldn't be suggested to be. Otherwise what do you do in the XmlSerializer when you come across an offset? Throw an exception as you can't parse it? Parse it without the offset and lose the ability to roundtrip data from xml?
Basically either drop the idea this is usable in xml for xs:time or make the data type able to roundtrip data with no loss.

[mconnew]

@YohDeadfall, adding support to DataContractSerializer isn't as simple as you think. We have the .Net native pre-gen serializer implementation which isn't open source which needs to be updated to match. XmlSerializer also needs support added. NetDataContractSerializer would also need support, although I don't think that's available on .Net core. Then you have the JsonDataContractSerializer would also need updating. We have our svcutil application for generating WCF proxies, WCF Connected Services too. And this would need to be done in a way so as not to break people who already do their own serialization of the xs:time xml type. Adding @shmao and @zhenlan who own the serializers.

[mattjohnsonpint]

Don't we already get DataContractSerializer support by implementation of IXmlSerializable and XmlSchemaProviderAttribute being implemented on the types? Why do we need to do anything else?

Regarding the optional offset allowed by XSD, I would expect it would drop an offset if encountered on deserialization. However, I can understand that might be seen as a bug. Then again, I also expect xs:dateTime with an offset to be serialized as a DateTimeOffset, and it does not. Instead we are introducing a custom type and we separate the datetime and offset portions into two fields.

So, since it seems we're already in the game of using custom types, I suppose we could serialize these two as custom types as well. Using a restriction facet, which would be almost identical to this example in the XSD docs, would more precisely align the types with XSD:

<simpleType name='bare-date'>
  <restriction base='date'>
    <pattern value='[^:Z]*'/>
  </restriction>
</simpleType>

Or would this confuse folks even more?

I can implement this easily, as XmlSchemaPatternFacet is available in .NET Standard 2.0.

[YohDeadfall]

@mj1856 The problem is that the IXmlSerializable interface is located in System.Private.Xml. This makes impossible to land the types in the System.Runtime package.

[mconnew]

@mj1856, DataContractSerialier et al handle xml primitive types natively and don't use anything like IXmlSerializable. As xs:time is an xml primitive, the convention is that the serializers have innate knowledge how to handle them. IXmlSerializable is meant for custom serializable types. As for how xs:datetime is handled, just search stackoverflow or use your favorite search engine and look for issues people have with it and .Net. This has caused a lot of confusion and difficulty in the past. A restrictive facet depends on there being an xsd available. For WCF usage, we could potentially emit a restriction facet when creating a wsdl, but we aren't set up to consume very many xsd restrictions so it would be a lot of work to detect the restriction and then choose the new Time work as there's no framework that already exists to take that into account.

[mattjohnsonpint]

I see. Well then, it seems that the best option would be to remove the XML serialization aspect from the structs entirely. Then other components can determine whether or not to support them, when, how, etc. separately. Or are there other ideas?

[mconnew]

I think it ultimately comes down to what is the justification/reasoning for adding these types? Is the primary reason to enable marshalling back and forth to the web? In which case what would be the right choice when designing a data type from scratch is irrelevant as you need to map to the existing data types that someone else has designed. Then any disagreement with the design choices made by others in other standards is incompatible with the purpose of the types. If this is for web interop, these types should primarily be considered convenience OM types which only need basic manipulation methods and the primary focus should be making sure they suit the function of losslessly serializing to and from web formats. This would mean they should have a timezone field, even if conceptually it doesn't make sense. If this is intended for HTML5 usage only, then what's the justification for excluding XML beyond "I don't like how they wrote their standard"? I this is to facilitate HTML5 only then personally I think we should reject the proposal to add the types to the framework.
So I see 3 possibilities:

1. This is primarily for web standards including xml and the types should contain timezone info and the work should be done to add support to the serializers.
2. This is for use with some web standards (e.g. HTML5) but is intentionally not designed for use with XML in which case timezone info isn't needed and no work is needed in the serializers. If this is limited to HTML5 usage, then I would argue it shouldn't live in the framework and should be a type owned by an asp.net assembly. I don't think that adding a new type to System.Runtime for a single narrow usage is the right thing to do.
3. The types are being proposed independent of any usage on the web. If this is the case, then I would ask what's the deficiency in DateTime that needs solving? Could it be solved with new api's on that type?

[YohDeadfall]

1. Having timezone in Time and Date without needing it is a bad idea. Probably we should add TimeOffset and DateOffset as proposed in Simplify name of the TimeOfDay struct #1870 (comment).
2. Not only. That types should be also used by data providers for example. See https://github.com/dotnet/corefx/issues/700.
3. See https://github.com/dotnet/corefx/issues/2116 and https://github.com/dotnet/corefx/issues/700. In short there are no types to represent date and time separately.

/cc @jskeet

[mconnew]

Before any discussion about what values should be stored in a type, you need to define the purpose, the intended usage for that type. Can we define that first? Below is just a discussion of why this is important but this is the key point. A new type needs to be suitable for its intended purpose (which probably should include explicit non-goals) and unless that's defined, people will be talking at cross purposes.

1, That was my whole point. If this is meant for use with web standards including XML, then timezone is needed. It's needed to be able to roundtrip the data without information loss. Regardless if you think the information has any value or not, it's part of the XML spec and not having it in the .Net data type does mean there will be information loss when round tripping.
2. This has similar aspects to the issue with XML. For example, DateTime has a precision of 100-nanoseconds. I don't know enough about SQL's date type, but lets pretend for a moment it has a precision of 1-nanosecond. Then any data type designed for use with SQL would need to store the value to that precision. A data type which can be used for round tripping data to an external source needs to be able to reproduce it's input otherwise really bad things can happen (e.g. optimistic locking by using a where clause in a SQL update statement to ensure nobody else has modified the data before you fetched it would fail if the precision wasn't sufficient). If this is designed for interop with external sources, this needs to be explicit and evaluated. I have no reason to believe this will be a problem with SQL Server, it just demonstrates that the type needs to be appropriate.
3. There's no data type to represent a particular month either. You could say "but that's just the numbers 1 to 12" or "that's just a list of constants", but that misses something. If I create an enum for the months and the month is February, how do I know how many days are in that month? If I have an app which shows an entire months schedule, what data type would I pass to a method which displays the entire month? The proposed Date type won't work as it includes the day and I don't want the day. This is a similar analogy to what
at cross purposes.
was mentioned earlier about specifying a specific day on a calendar but instead applied to a month where a month represents an entire page on a calendar. Should we have a data type for that? If you say the answer is to use the proposed Date type with some convention like the day of the month being 1, then that's no different than saying a Date can be represented by a DateTime with the time element as midnight.

Basically what I'm saying is the first question that needs to be answered is why? Why is Date and Time needed? Is the reason because of deficiencies in DateTime/DateTimeOffset? Is so, then why is Date needed but not Month? What about Hour? Or is the reason for interop with external sources more easily? If so, then what's the list of target external sources? SQL? What about Oracle, MySQL, PostgreSQL? What about web standards, HTML5, XML, JSON, E-Mail, HTTP date headers, SMTP date fields? ISO-8601 profiles, which profiles? If this is for use with external sources, it needs to be stated which external sources are goals to interop with and each evaluated to work out if the proposed solution will work with it.

[mattjohnsonpint]

@mconnew - you bring up a good point, but the "why" has already been asked and answered. We're well past that point. This work is the result of long discussions in dotnet/corefx#700 and dotnet/corefx#2116. If you've read through those and feel it's still not clear why these types are needed, please let me know. Perhaps I can summarize more succinctly.

[mattjohnsonpint]

@YohDeadfall respectfully, I really don't think OffsetDate and OffsetTime types have as broad applicability as Date and Time types would have.

In general, trying to cover all edge cases in the domain of date and time will eventually lead to a design like Noda Time, which is already available for those that need it. I've expanded nodatime/nodatime#864 to discuss adding OffsetTime and OffsetDate with regard to XSD compatibility. Feel free to chime in over there. Thanks.

[YohDeadfall]

@mj1856 I'm fully agree with you, DateOffset and TimeOffset will be rarely used. But without them there are problems with serialization out of the box.

Is it a good idea to publish the types with partial serialization support (without timezones)? For many devs it would be enough for now I think.

[drieseng]

I'm all for these new types, but specifically for XML/SOAP (de)serialization I would either like to have serialization support that is fully compatible with XML Schema data types (meaning with timezones), or no serialization support at all.

I would prefer the former, but the latter may at least allow "us" to add full serialization support in a future iteration without introducing breaking changes.

Having support for XML Schema data type (de)serialization that mostly works should be avoided.

[mattjohnsonpint]

@mconnew and I met in person yesterday to discuss the tradeoffs and different approaches. The consensus we came to is that if Date and Time are to be treated as primitives that they will indeed need to be directly and fully aligned with xs:date and xs:time. I have written up the plan in #1901. Please use that issue for any discussion around XSD and offsets.

I'd still like to leave this issue open for other discussion around promoting this to corefx. Thanks.

[mattjohnsonpint]

Closing this, just because I already have issues open for each specific item remaining. When complete, I'll open API request issues in corefx. Thanks all.

[ygoe]

@mj1856 I've been coming here after reading your older vision about date/time handling in this comment. I find it hard to track this since it seems to be spread all over the place. Is there a place I can track this to find out when I can use the new types in entirety?

[Dreamescaper]

Is it possible to reopen this issue?
I haven't found any open issue to track this work, all other items are closed.

[tarekgh]

@Dreamescaper I am looking at some issues including this one for the planning. Could you advise which types you are interested in from this library and explain more about your usage and need for it? I am just gathering some data regarding such features and the requests. Thanks.

[Dreamescaper]

@tarekgh
I'm interested in Time class most of all.
Right now I'm working on API to store shop working hours.
I'm using TimeSpan type to represent time of day in request types and DB models, but it's quite painful - I need to add separate validations for >0 and <24h etc.

I could use DateTime type, and consider Time component only, but it leads to issues with serialization - DateTime.Parse("07:00").ToString() -> "11/9/2020 7:00:00 AM".

I often need separate Date type as well, but it's a bit less painfull to use DateTime type for Date only (comparing to case with Time only).

[OskarKlintrot]

@tarekgh
I'm instead interested in the Date class most of all.

We have a lot of products that is valid from date X to date Y. When we used DateTimeOffset we always had to remember to start at date X 00:00:00 and end at date Y 23:59:59.999. Then we switched to NodaTime and used LocalDate from there and all a sudden we could just compare dates without bother about time. We store Date in the database and map the column to a LocalDate now instead of a DateTimeOffset (which makes no sense since Date in the DB don't have time or offset) which makes our lives even easier.

[ilmax]

I'm also interested into the type Date. In my experience it's a fairly common requirements to compare only dates, using a DateTimeOffset implies you have to always remember to ignore the time part whenever you have to do some comparison, having a Date object would make it explicit.

[tarekgh]

@OskarKlintrot @ilmax it is useful feedback. thank you.

would you need formatting and parsing functionality for the Date and Time. I am seeing @Dreamescaper mention he is using Parsing but I am interested what kind of functionality you need with these classes?

[OskarKlintrot]

For our use case we are just deserializing from json or mapping from Date in SQL Server and presenting the date as YYYY-MM-DD for the end user. So very basic formatting and parsing. Not sure what more to add :)

[ilmax]

Ideally I would like the Date type to have the same support other System type has (e.g. DateTime) so just to name a few in no particular order:

• asp.net core model binding support
• serialization support (also S.T.J and gRPC)
• ef core mapping support

so I would love to see this new Date object to be a first class citizen of .net 6.0

[OskarKlintrot]

@ilmax puts it better than I do, listen to him instead of me 😛

[mconnew]

@ilmax, serialization is a difficult thing to achieve. For example, for XML, there is the xsd:date datatype, but it has an optional timezone. This issue was originally to support the date and time types used in HTML forms as defined by HTML5. The HTML5 date datetype doesn't include the timezone. So what do you do if you try to deserialize some XML with an xsd:date that has a timezone? Then we get to JSON, what's the right thing to do there? There is no official date format for JSON, it's just a string which an application can choose to interpret as a date. The JavaScript method Date.toJSON outputs a date and time with a timezone in ISO8601 format. But many people use a number which represents milliseconds since 1970 as that's what the JavaScript Date constructor accepts. Then you get to Protobuf which has no definition but Google has published a "Well Known Types" extension which has a Timestamp datatype. Reading the spec on that, it's similar to the general JSON approach, but is a number representing nanoseconds since some starting point. It doesn't have any concept of timezones, but it does represent an exact point in time. Which means a Protobuf Timestamp will represent different calendar dates for different timezones. So there is no way to simply represent an unambiguous date over gRPC without inventing some new over-the-wire representation. And I haven't even mentioned the issue of SQL.

And this is the crux of the problem. If you define a date or time datatype with the purpose of being used in a particular context (in this case originally HTML5), that datatype will be unsuitable for other contexts. Within .NET the only thing you can really do is create a Date and a Time datatype for representing a simple Date or a simple Time with no intended purpose to use with any particular technology such a gRPC or WebAPI and then have each technology have it's own defined type representing the full fidelity of what that technology can represent. For example, gRPC can give you an exact point in time down to the nanosecond, but no data about timezone so then it's up to the application developer to decide how to handle the timezone issue if they just want a date. E.g. pick a timezone and use noon in that timezone and roundtrip dates with that. Or with XML, you have to decide what you want to do with the timezone, store it separately, ignore it, treat it's presence as an error?

So if everyone is going to need to have their own representation for a date and a time based on their technology, what's the purpose of the Date and Time classes? They don't make any sense in isolation and are insufficient for every possible usage there is. Personally I'd prefer to see a suite of data types. An XmlDate, an XmlTime, an XmlDateTime, a protobuf TimeStamp, and for JSON, maybe a helper class which can consume and emit a range of popular formats used. But that would be down to each library to create and not a central type defined in the System root namespace.

[OskarKlintrot]

I don't mean to diminish or invalidate what you are saying but remember that NodaTime (and JodaTime, I presume) have had Date and Time for years now that can be serialized and works out-of-the-box for millions of developers. NodaTime have ~22 million downloads so I would say that the need for a Date and Time is very real for a lot of developers. Also, note that @ilmax is specifically mentioning serialization with System.Text.Json, not as part as CoreFx. IMHO parsing should be though (so pretty much just as DateTimeOffset and System.Text.Json works today or NodaTime.LocalDate and NodaTime.Serialization.SystemTextJson).

Date in JS accepts ISO8601 btw :)

[ilmax]

@mconnew thanks for the deep explanation, I wasn't aware of all these limitations. It's indeed a pity to not have industry wide standards on how to serialize a date and a time, but I still think there's some value in having them also to somehow achieve parity with other languages.

• JDK 8 added support for date and time (article)
• Python also appears to have support for date and time (docs)

[ygoe]

Databases have several date/time data types. And each has their own set of types. Obviously, you can only use a .NET type that somehow matches the SQL type. This is the responsibility of the programmer.

For exchange formats there is ISO 8601. It defines about every possible selection and combination of dates and times and time spans and ranges and what not. So I see no problem with transferring any date or time to another system. And if that other system requires the data in a specific/custom format, the programmer again has the task to provide/accept it accordingly. It's not like there would be a universally accepted format today, so no compatibility can be broken here.

None of this limits the possibility of the existence of types like Date or Time alongside DateTime or DateTimeOffset or TimeSpan (which is very limited right now, compared to ISO 8601). In fact, I could easily create them myself in my own application and add casting operators for ease of use. It would simply be helpful if the framework already included those. I see more work in the support of EF Core which would need to convert the data. Maybe I'm even allowed to provide those converters, too.