Adds support for TimeOnly constructors (from parts and from ticks) in queries for majority of providers.
Some providers (or versions of them) require special and not the best way to construct TIME values but save way in terms of value range. If there is a function to create a time value, we use it (e.g. MS SQL Server from v11, PostgreSQL from v10). In other cases, there are following ways:
1) add all time parts one by one to 00:00:00.000 time value;
2) compose a string of time value and then cast it to time.
Both of them have certain overhead but the second one provides boundaries check and an exception will be thrown if cast from string fails, which is good. The first way will have value overflow problem when there are more than 24 hours, which is possible.
Cases when TimeSpan.Ticks is used as parameter value for TimeOnly(ticks) constructor are handled additionally, to have less calculations.
Excluded providers are: SQLite, MySQL providers. These RDBMSs have certain particularities which were disqualifying.
SQLite: TIME values can have range, which is wider than TimeOnly's range, for example, 24:05.xx.xxx is valid value. The other part of problem is that there is no way to guarantee correct value even if it is wrong (25:05:xx.xxx). Storage will return NULL instead of exception of some sort. NULL value may be valid in case of Nullable<TimeOnly> persistent field which may cause wrong results of query. Value overflow is not an option because it also may lead to unexpected results.
MySQL: TIME value have range from -838:59:59.000000 to 838:59:59.000000, which is part of the problem the second part is that even if hour part is 839, the storage does not throw any errors but return max value. If there was an overflow error we could mathematically overcome this problem by adding 815 hours and then subtracting this value from result time value, but we can't. Newer versions have MAKE_TIME function which also doesn't control parameters, even if string is used as value, it will return NULL which may be valid value.
Adds support for
TimeOnly
constructors (from parts and from ticks) in queries for majority of providers.Some providers (or versions of them) require special and not the best way to construct
TIME
values but save way in terms of value range. If there is a function to create a time value, we use it (e.g. MS SQL Server from v11, PostgreSQL from v10). In other cases, there are following ways: 1) add all time parts one by one to00:00:00.000
time value; 2) compose a string of time value and then cast it to time.Both of them have certain overhead but the second one provides boundaries check and an exception will be thrown if cast from string fails, which is good. The first way will have value overflow problem when there are more than 24 hours, which is possible.
Cases when
TimeSpan.Ticks
is used as parameter value forTimeOnly(ticks)
constructor are handled additionally, to have less calculations.Excluded providers are: SQLite, MySQL providers. These RDBMSs have certain particularities which were disqualifying. SQLite:
TIME
values can have range, which is wider thanTimeOnly
's range, for example, 24:05.xx.xxx is valid value. The other part of problem is that there is no way to guarantee correct value even if it is wrong (25:05:xx.xxx). Storage will return NULL instead of exception of some sort. NULL value may be valid in case ofNullable<TimeOnly>
persistent field which may cause wrong results of query. Value overflow is not an option because it also may lead to unexpected results. MySQL:TIME
value have range from-838:59:59.000000
to838:59:59.000000
, which is part of the problem the second part is that even if hour part is 839, the storage does not throw any errors but return max value. If there was an overflow error we could mathematically overcome this problem by adding 815 hours and then subtracting this value from result time value, but we can't. Newer versions haveMAKE_TIME
function which also doesn't control parameters, even if string is used as value, it will returnNULL
which may be valid value.