Inconsistent time type usage

[leighmcculloch]

What version are you using?

2674d86

What did you do?

Used get_ledger_timestamp to get timestamp.

rs-soroban-env/soroban-env-common/env.json

Lines 77 to 83 in e2f9c1d

	{
	"export": "4",
	"name": "get_ledger_timestamp",
	"args": [],
	"return": "U64Val",
	"docs": "Return the timestamp number of the current ledger as a u64."
	},

What did you expect to see?

A Timepoint.

What did you see instead?

A u64.

Discussion

We seem to have these two types Timepoint and Duration that get exposed all the way up in the SDK, however they don't seem to get used anywhere. Even the places in the host interface where one might think a time would be exposed like the get_ledger_timestamp function, they just use a plain u64.

What are Timepoint and Duration for? Should we remove them if they aren't in use? Or are there places that aren't using them should be using them?

History

It looks like timepoint and duration were added in:

• Support Timepoint, Duration #866

In response to this issue:

• Add host functions to transport objects between host and guest memory for String, Timepoint, Duration  #724

According to this comment it sounds like the intent was to use Timepoint for the ledger timestamp:

They can represent for example ledger timestamp and can specify its own display format

Ref: #866 (comment)

@jayz22 @graydon What should we do here?

[graydon]

"What they're for" is explained in the comment you linked to: #866 (comment), they're numbers with absolute and relative time semantics implied (for formatting and, presumably, to dangle datetime-arithmetic functions on at the SDK level). They exist in the XDR already, we're just not returning the right type here. We should change the host interface.

[graydon]

Can the SDK move ahead with providing Timepoint to users? The env change doesn't seem to me a particularly high priority, is it? (We can of course change at some point, I am just trying to figure priority)

[leighmcculloch]

It could but it'd require adding more host function calls. The SDK would get a u64, then need to convert it into a Timepoint, then give someone that Timepoint object. So we could do it in the SDK now, and do later in Env if the additional host fn call is bothering folks.