Investigate migrating `Duration`'s internal representation from `FiniteF64` to `i64` or potentially `u32` and `u64`.

[nekevss]

Currently, Duration uses FiniteF64 for it's field. It would be nice to move away from FiniteF64 for the internal representation and use i64 or u32 and u64.

Below are some pseudo representations (not including DateDuration or TimeDuration):

struct Duration {
    years: i64,
    months: i64,
    weeks: i64,
    days: i64,
    hours: i64,
    minutes: i64,
    seconds: i64,
    milliseconds: i64,
    microseconds: i64,
    nanoseconds: i64,
}

struct Duration {
    sign: Sign,
    years: u32,
    months: u32,
    weeks: u32,
    days: u64,
    hours: u64,
    minutes: u64,
    seconds: u64,
    milliseconds: u64,
    microseconds: u64,
    nanoseconds: u64,
}

General things that need to be considered.

1. How will this interface with engines where inputs may be in a range of 2^53 - 1?
2. Is there any point in the operations of the Temporal specification where precision on an unbalanced duration may matter?
3. Should DateDuration and TimeDuration be preserved in favor of using the above as the external Duration and a new "internal Duration" for calculation purposes?

[nekevss]

Update on the progress here.

Currently, the Temporal proposal relies on behavior related to floating point arithmetic for integers above the MAX_SAFE_INTEGER for Duration validation in IsValidDuration. This may also extend to add and subtract operations. This complicates the representation that can be used for millisecond, microsecond, and nanosecond due to both microseconds and nanoseconds exceeding a range of i64 and u64.

Unit	Largest Valid Duration
nanosecond	9_007_199_254_740_991_463_129_087
microsecond	9_007_199_254_740_991_475_711
millisecond	9_007_199_254_740_991_487

Note the size of an i64::MAX and u64::MAX vs. the largest microsecond value.

    9_223_372_036_854_775_807 // i64
   18_446_744_073_709_551_615 // u64
9_007_199_254_740_991_475_711 // largest micros

[jedel1043]

@nekevss Is that intentional from the spec, or can we ask the champions to relax the range requirements for microseconds and nanoseconds to fit the range of an i64 ?

[nekevss]

The issue file on the proposal is here.

tc39/proposal-temporal#3106

We couldn't have nanosecond be in the i64 range even if we wanted to (I believe it wouldn't be able to support the JS date range). There's potential for the microseconds to be in an i64 range if the check was shifted from seconds to milliseconds. I'm not sure if that will happen.

I think best case scenario if there were updates would be:

struct Duration {
    years: i32,
    months: i32,
    weeks: i32,
    days: i64,
    hours: i64,
    minutes: i64,
    seconds: i64,
    milliseconds: i64,
    microseconds: i64,
    nanoseconds: i128,
}

They would have to adjust the validity checks on years, months, weeks and shift the time unit check. It would eliminate one of the max duration options and save 4 bytes as best case scenario.

Another option would be to specify the fields different depending on feature flagging. Then keep the floating point for javascript, and lessen the range for native Rust. I'm not really sure, tbh. It's a really strange type to optimize.

Any ideas?

EDIT: also, interestingly, I think the unsigned version would be more bytes not less ... although, I haven't actually checked the layout and alignment, so that may throw a hitch in which is better.

[jedel1043]

Wild idea, what if we use something like:

struct Duration {
    years: i32,
    months: i32,
    weeks: i32,
    days: i64,
    hours: i64,
    minutes: i64,
    seconds: i64,
    milliseconds: i64,
    microseconds: i80,
    nanoseconds: i128,
}

It should cover the larger microseconds range, and thanks to alignment it still should have the same size as the original Duration. I think the bnum crate implements a packed i80 type which uses five u16 instead of an i128.

[nekevss]

1. That's super interesting, and I'm going to be taking a look at that crate.

2. It's an option, but we still have to use i64 currently for years, months, and weeks unless we change to the unsigned type, so the type is still larger than what it could be.

[nekevss]

Also, just to note: we can use a i80 and i88 to represent the current fields if we are trying to be super efficient.

i88::MAX (2^87) = 154_742_504_910_672_534_362_390_528 // Nanoseconds fit!
i80::MAX (2^79) = 604_462_909_807_314_587_353_088 // Microseconds fit!