Closed alex-kulakov closed 1 year ago
@SergeiPavlov, Is this a problem that there is no new TimeOnly(ticks)
support?
@SergeiPavlov, Is this a problem that there is no
new TimeOnly(ticks)
support?
Why no support? https://learn.microsoft.com/en-us/dotnet/api/system.timeonly.-ctor?view=net-8.0#system-timeonly-ctor(system-int64)
The guys in DPA are waiting for at least RC to work with it in development branch so it is mostly because of timings. I'm going to add it later.
Adds support for these new types of .NET6 to all supported storages. This PR includes #251 and makes some changes over it.
Main changes:
SqlDml
methods for operations with these types, such as parts extraction, additions/subtractions, construction from parts, value conversion betweenDateTime
,DateOnly
,TimeOnly
andDateTimeOffset
(when and if possible)ChangeFieldTypeHint
is applied.Depending on storage,
TimeOnly
values will have different precision when stored - from 7 for MS SQL Server and Oracle, to six and sometimes 4 fractional digits. MySQL 5.5 (provider still exists thought it was excluded from the supported storages due to age age) has no support for time fractions.SQL types
DATE
andTIME
are used forDateOnly
andTimeOnly
respectively, except for Oracle in which there is noTIME
type so we usedINTERVAL DAY (0) TO SECOND(7)
. TIME behavior on storage side differentiates between RDBMSs and .NET, for example even so MySQL can store more that 800 hours in TIME operation of adding interval to it will always have not more than 23 in 'hour' part as it is in .NET. Expect .NET-like operations.On data conversion in case some field (and underlying column) changes type between
DateTime
/DateOnly
/TimeOnly
/DateTimeOffset
, the conversion happens on storage side. We don't assume and use internal mechanisms whenever it is possible, but sometimes we have to. There is some variation of results of conversion.DateOnly-to-DateTime
conversion is predictable and uses zero-time across the board.TimeOnly-to-DateTime
conversion has a lot of difference:TIME
toDATETIME2
, MS SQL Server internal mechanisms use'1900-01-01'
as date (under the hood it puts0000-00-00
as date part but since it is invalid it replaces it with1900-01-01
).0001-01-01
is valid date, it was made so because naturallyto_timestamp(0)
returns1970-01-01
, not the0001-01-01
. So, for people who work with PostgreSQL this date will be known and expected.0001-01-01
.1900-01-01
as date.TimeOnly-to-DateTimeOffset
is tricky too. Conversion uses same principals for date part as above but time zone part applied to the value changes depending on RDBMS and even value. For more context take a look atXtensive.Orm.Tests.Upgrade.DateTimeTypesDataConversionTest
TimeOnly-to-DateOnly
causes an exception for all storages except for SQLite (but it's its own thing) for obvious reason.NOTE There is no support for TimeOnly(long ticks) constructor and TimeOnly.Ticks part yet.