[STABILITY] Specific Timestamp type in the SDK

[cloutiertyler]

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.

[mamcx]

I agree is desirable to have concrete types. The issue is that dates have several:

https://docs.rs/chrono/latest/chrono/

This probably require a proposal

[cloutiertyler]

I'm going to leave this open, but I suspect this should really be defined by: https://github.com/clockworklabs/SpacetimeDBPrivate/issues/839

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.

[gefjon]

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.

[joshua-spacetime]

Tentatively downgrading this to P2 for now as per conversation with @gefjon.

[gefjon]

After merging, investigate blackholio and find all the breakages. Hopefully they will be small. Coordinate with @cloutiertyler to get those changes into the tutorial video.