More explicit date-and-time resource #7
Comments
5 tasks
|
@Mossaka, this would, more or less, duplicate what wasi-clocks/wall-clock already does; so, reusing what's already provided might be a better approach than building anew. |
Yeah that makes sense. Thank you for bringing this up! |
thomastaylor312
added a commit
to thomastaylor312/wasi-blobstore
that referenced
this issue
Jul 29, 2024
This is a relatively simple PR that mostly restructures things. This removes the container interface because there wasn't much you could do with it by itself, it always had to be used in conjunction with the blobstore interface. I also got rid of all of the type aliases for strings to make the types interface cleaner, as well as follow what we've been doing in the other wasi cloud interfaces with avoiding type aliases. Additionally, I updated the timestamps to use the wasi-clock timestamps instead so we were using a concrete type. That was the only major change here, but it does solve an outstanding issue we have. Closes WebAssembly#7 Signed-off-by: Taylor Thomas <[email protected]>
rvolosatovs
pushed a commit
to rvolosatovs/wasi-blob-store
that referenced
this issue
Aug 16, 2024
This is a relatively simple PR that mostly restructures things. This removes the container interface because there wasn't much you could do with it by itself, it always had to be used in conjunction with the blobstore interface. I also got rid of all of the type aliases for strings to make the types interface cleaner, as well as follow what we've been doing in the other wasi cloud interfaces with avoiding type aliases. Additionally, I updated the timestamps to use the wasi-clock timestamps instead so we were using a concrete type. That was the only major change here, but it does solve an outstanding issue we have. Closes WebAssembly#7 Signed-off-by: Taylor Thomas <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently timestamp is defined as a
u64type, which doesn't really specify what kind of date and time representation it is. It might be seconds since Unix Epoch or it might noe be. I would suggest to come up with a more explictly date and time resource which provides methods to convert timestamp to different representations. Minimally, it should contain two methodsunix_timestamp() -> i64to get the Unix timestampunix_timestamp_nanos() -> i128to get the Unix timestamp in nanosecondsIn addition, we might want to consider adding
fromfunctions to convert unix timestamp this sturct as constructors.We may want to define other functions such as
dateandtimeto return date and time representations resp.CC @devigned
The text was updated successfully, but these errors were encountered: