How to construct `clock_time_point` class objects from two internal numbers (lower and upper)?

[eitsupi]

I would like to implement interconversion with the clock_time_point class in the polars package. (clock -> polars is here pola-rs/r-polars#861)

Polars holds the datetime as an Int64 type, so I am thinking that the conversion to clock_time_point needs to be converted to two UInt64 types in Rust and then passed to two double in R.

I am wondering if there is a way to create an clock_time_point class object from two R's double.

I am not familiar with the vctrs package and C++, so do not fully understand how the clock_time_point class is constructed.

Thanks in advance.

[DavisVaughan]

I have not yet exposed a way to convert from low level types (like a C int64_t) to the pair of doubles that clock expects.

I think you found it already but the key bit is

clock/src/duration.h

Lines 133 to 184 in adc01b6

	/*
	* This pair of functions facilitates:
	* - Splitting an `int64_t` into two `uint32_t` values, maintaining order
	* - Combining those two `uint32_t` values back into the original `int32_t`
	*
	* The two `uint32_t` values are stored in two doubles. This allows us to store
	* it in a two column data frame that vctrs knows how to work with, and we can
	* use the standard `NA_real_` as the missing value without fear of conflicting
	* with any other valid `int64_t` value.
	*
	* Unsigned 32-bit integers are used because bit shifting is undefined on signed
	* types.
	*
	* An arithmetic shift of `- std::numeric_limits<int64_t>::min()` is done to
	* remap the `int64_t` value into `uint64_t` space, while maintaining order.
	* This relies on unsigned arithmetic overflow behavior, which is well-defined.
	*
	* Taken from vctrs:
	* https://github.com/r-lib/vctrs/blob/c27b6988bd2f02aa970b6d14a640eccb299e03bb/src/type-integer64.c#L117-L156
	*/
	CONSTCD14
	static
	inline
	std::pair<double, double>
	int64_unpack(int64_t x)
	{
	const uint64_t x_u64 = static_cast<uint64_t>(x) - std::numeric_limits<int64_t>::min();
	const uint32_t left_u32 = static_cast<uint32_t>(x_u64 >> 32);
	const uint32_t right_u32 = static_cast<uint32_t>(x_u64);
	const double left_out = static_cast<double>(left_u32);
	const double right_out = static_cast<double>(right_u32);
	return std::make_pair(left_out, right_out);
	}
	CONSTCD14
	static
	inline
	int64_t int64_pack(double left, double right)
	{
	const uint32_t left_u32 = static_cast<uint32_t>(left);
	const uint32_t right_u32 = static_cast<uint32_t>(right);
	const uint64_t out_u64 = static_cast<uint64_t>(left_u32) << 32 | right_u32;
	const int64_t out = static_cast<int64_t>(out_u64 + std::numeric_limits<int64_t>::min());
	return out;
	}

It makes me fairly nervous for polars to rely on these internal details since I haven't exposed anything for it yet. In fact, I only somewhat recently changed to this approach, and made massive internal changes in the underlying storage model. I would not have been able to do that as easily if polars was relying on the previous internal storage model.

Would it be possible for you to use an exposed API to go polars <-> string <-> clock for now? I don't have the time right now, but when I next do a sizable release of clock I can try and expose some developer facing interface to help you out.

[eitsupi]

Thanks, that sounds good.
The polars package is not released in CRAN so I don't think it will be a problem if it breaks with the clock update, but I will try to update it to use string.