Missing operation: truncating tToInstant for Long-based time values

[benhutchison]

I realised there's a missing operation in the time module.

toInstant is non-truncating and is backed by conversions for fraction value types like Double. But there's currently no tToInstant for discrete value types like Long.

It's counter-intuitive to think of truncation occurring when converting to an Instant, but it's theoretically possible if the time value was in nanos.

Anyway, Coulombs machinery wants truncating conversions for Long; ie in time.scala, EpochTimeInstant is built from DeltaUnitConversion, but what's needed is a cousin TruncatingEpochTimeInstant built from a TruncatingDeltaUnitConversion.

[erikerlandson]

@benhutchison my take on this was that conversion to java Instant or Duration will never truncate because those data structures have millisec or sub-millisec components. You can see in my conversion code where I compute those.

[benhutchison]

To be clear, I don't care about possible truncation on Instant either. But empirically, I found that toInstant on Long-based timestamps won't compile. When I went looking for why, it seems that DeltaUnitConversion isn't available for Long in Coulomb ATM, only TruncatingDeltaUnitConversion.

[erikerlandson]

Ah, the truncating unit conversion is gating. That would be part of the constellation of issues having to do with non-implicit truncating rules. An importable policy supporting those would fix these for you.

[benhutchison]

Hi @erikerlandson is this policy something I could put together, to enable me to continue my experiment (ie rolling out Coulomb into a test codebase)?

Any hints on what not/to include would be appreciated..

[erikerlandson]

I think what you have in mind is to define UnitConversion and ValueConversion rules for Long and Int.

For examples, I'd start here:

• https://github.com/erikerlandson/coulomb/blob/scala3/core/src/main/scala/coulomb/conversion/standard/unit.scala
• https://github.com/erikerlandson/coulomb/blob/scala3/core/src/main/scala/coulomb/conversion/standard/value.scala

I definitely intended that library users could define their own custom rules (policies), and I wanted this to be as intuitive as possible (I tried to include a bit of exposition on this in the docs but perhaps I should add more).

[benhutchison]

Ok, so I'm still a bit confused, having trouble joining some of the dots between my original problem and your hints. I'll try to explain.

I observed that toInstant didnt work for Long and went looking for why.

I saw it needs an EpochTimeInstant and found where EpochTimeInstant comes from.

In turn it needs:

                vc: ValueConversion[V, Rational],
                uc: DeltaUnitConversion[
                    Rational,
                    coulomb.units.si.Second,
                    U,
                    coulomb.units.si.Second
                ]

It seems that Long doesn't come with a DeltaUnitConversion but rather a TruncatingDeltaUnitConversion.

So in my original post ☝️ I assumed the solution was

• a variant tToInstant that takes a TruncatingEpochTimeInstant
• an implicit that builds TruncatingEpochTimeInstant from a TruncatingDeltaUnitConversion, which is already defined for Long.

Ah, the truncating unit conversion is gating. That would be part of the constellation of issues having to do with non-implicit truncating rules. An importable policy supporting those would fix these for you.

But your reply above suggested another approach involving implicit conversions, but I'm not sure how this is intended to work. What would be converted, would it be eg TruncatingDeltaUnitConversion => DeltaUnitConversion?

[erikerlandson]

You are right that there is more than one possible way to do this. The way I had in mind was defining rules to create DeltaUnitConversion for Long. Similar for UnitConversion (and also ValueConversion).

a variant tToInstant that takes a TruncatingEpochTimeInstant

This is another way, but IIRC, you had also run into similar confusion outside of the time library, and the DeltaUnitConversion rules for Long and friends should fix it "everywhere"

[benhutchison]

OK, I've realised some of my conclusions/statements above were wrong and I was misunderstanding the problem.

I'm going to start a new thread because the title of this one is misaligned with the problem I'm seeing now. I'll try and start with the actual problem Im seeing.

But I'll mention that toInstant work for Long values here in this test so my hypothesis about Long simply being unsupported is not correct.

    test("toInstant") {
        import coulomb.units.javatime.conversions.explicit.given

        val et = (-165L).withEpochTime[Day]
        assertEquals(et.toInstant.toString, "1969-07-20T00:00:00Z")
    }

[benhutchison]

Think I finally minimized the issue. Minimisation is hard work 😓
#419