Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Duration with values >= 24h #38

Open
Isitar opened this issue Feb 6, 2024 · 3 comments
Open

Duration with values >= 24h #38

Isitar opened this issue Feb 6, 2024 · 3 comments

Comments

@Isitar
Copy link

Isitar commented Feb 6, 2024

Hello

Since your DataType for a Duration is time Values >= 24h are not supported.
Do you plan on changing it or at least hint at it in the documentation?

@StevenRasmussen
Copy link
Owner

@Isitar - The main reason for choosing this type was so that queries would translate to SQL and just work with where clauses. I'm open to suggestions or pull requests if you feel there's a way to accomplish this by storing it as a string or another type. In the meantime, I can certainly update the documentation to reflect the current limitation.

StevenRasmussen added a commit that referenced this issue Feb 6, 2024
#38 - Adds verbiage to the documentation regarding the limitations of using the `Duration` type.
@Isitar
Copy link
Author

Isitar commented Feb 7, 2024

thanks for the update in the doc 👍

One option would be to store it as datetime2, this seems to work as long as the duration is less than a month
this article https://www.sqlteam.com/articles/working-with-time-spans-and-durations-in-sql-server gives more insight.

i'm not sure if it really works with everything like dailight-saving, leap year etc.

@corydambach
Copy link

corydambach commented Aug 21, 2024

I am also running into this, my workaround will probably be to store the duration as INT4 (count of minutes) and handle mapping myself.

From the NodaTime docs for Duration: "A duration is a length of time defined by an integral number of nanoseconds".

While for many applications this is probably overkill, but I think a Duration should probably map to BIGINT since that will be pretty easy and support a large range of Duration values.

In NodaTime, Duration's storage is implemented with two fields: Int32 days and Int64 nanoOfDay.

Using ToInt64Nanoseconds (shown below) to map from Duration => BIGINT should give around +/-292 years of range with nanosecond resolution (as documented below).

To read it back into a Duration use public static Duration FromNanoseconds(long nanoseconds)

/// <summary>
/// Conversion to an <see cref="Int64"/> number of nanoseconds. This will fail if the number of nanoseconds is
/// out of the range of <c>Int64</c>, which is approximately 292 years (positive or negative).
/// </summary>
/// <exception cref="System.OverflowException">The number of nanoseconds is outside the representable range.</exception>
/// <returns>This duration as a number of nanoseconds, represented as an <c>Int64</c>.</returns>
public long ToInt64Nanoseconds() ...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants