-
Notifications
You must be signed in to change notification settings - Fork 67
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
Timepoint and Duration types are difficult to construct in tests #1197
Comments
Thanks for adding this! I personally didn't even think to use XDR to initialize a |
All the SDK types, even custom types, are constructible via XDR ScVal's and convertible using into_val. The XDR conversions support other functionality like type generation in fuzz tests, etc. But it isn't intended to be the only way to construct types, and not intended to be the default way folks in tests or contracts to construct values. |
There are already private functions on Timepoint and Duration named
which is the same as: https://doc.rust-lang.org/std/time/struct.Duration.html#method.from_secs
which doesn't mirror the Rust stdlib because the way the Rust stdlib supports creating unix times is not particularly user friendly (see this)and given that unix time is the main way to represent time on Stellar I think we need something friendly. |
Definitely on board for What about something like this in impl Env {
pub fn now() -> Timepoint { |
It is possible to get a now-like Timepoint out of the env already with the following code. The reason for not providing env.ledger().timestamp() Unfortunately the Timepoint and Duration haven't really been adopted by the Host environment either... and that has the run on affect of the types being difficult to adopt in contracts. If the SDK is going to encourage their use the host environment should probably too. We might be able to add a |
### What Export functions for creating and accessing Timepoint and Duration. ### Why The types are not creatable inside a contract, and outside a contract in tests are only creatable using the XDR ScVal type. If developers are to use the Timepoint and Duration types, they need to be able to construct the types from primitive values. The `Timepoint` `from_unix` and `to_unix` functions were added using the unix terminologgy because that's the type of time values the Stellar network uses. The `Duration` `from_seconds` and `to_seconds` functions were added using the seconds terminology because it seemed like the most direct way to communicate intent. I originally intended to use `secs` which I think would also be reasonable and feedback on the issue suggested `seconds` which also seems reasonable to me. While for both types functions were repurposed/removed, those functions were private only and should have no impact on compatibility. Close #1197
What version are you using?
v20.0.3
What did you do?
Tried to create a
Timepoint
orDuration
using functions on the tests.What did you expect to see?
Some way to do that.
What did you see instead?
No way to do that.
Other than building the XDR and converting that way:
The text was updated successfully, but these errors were encountered: