You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Mario:
Then does this means adding chrono? Trying of use u64 instead internally is a footgun similar to how bool in SQLite is 1/0 (ie: Lets add proper date types, it also matters to match sQL spec)
If you use a timestamp in a table or as a reducer argument, then its going to generate a u64 which is unintuitive.
The text was updated successfully, but these errors were encountered:
Wherein we would just choose to use a u64 or something so as to not impose our own opinion about how you should represent timestamps in a given language.
Current status: A draft PR exists in SpacetimeDB, which needs a rebase. I opened a corresponding TypeScript SDK PR, which needs testing. We still need a C# SDK PR, which should essentially just be re-generating the Client API bindings, but we intend to wait on that until the C# SDK calms down a bit.
Mario:
Then does this means adding chrono? Trying of use u64 instead internally is a footgun similar to how bool in SQLite is 1/0 (ie: Lets add proper date types, it also matters to match sQL spec)
If you use a timestamp in a table or as a reducer argument, then its going to generate a u64 which is unintuitive.
The text was updated successfully, but these errors were encountered: