Interface type abbreviation for time?

[lachlansneff]

It might be useful to include a standard abbreviation for a time.

Something like this:

time ≡ (record (field "seconds" u64) (field "nanos" u32))

It would be defined as the duration elapsed since the unix epoch.

[lukewagner]

Great point! I've wondered about this too. The benefit (that you're probably also imagining) of having an explicit abbreviation is that each language would have the opportunity to bind time to that language's idiomatic time value (e.g., Date in JS). I don't know much about the subtleties of timestamp values, but what you wrote seems like a reasonable start. I see WASI time_get currently returns u64s. The downside of extra precision is perhaps a bit more work to convert between language native types, but it might be negligible; I dunno. It'd be interesting to see a list of languages and how they represent timestamps.

(cc @sunfishcode for another WASI perspective)

[sunfishcode]

WASI's u64s are 64-bit nanoseconds since the Unix epoch, which will run out in the year 2554. It's difficult to guess what anything in computing will need 500 years from now, however I'd guess we will end up expanding to a wider type even if it's just to match what most host OS's these days do.

[taralx]

Another factor to consider: is a timestamp wallclock time or monotonic time? Go, for example, uses both in an adaptive fashion.

[fgmccabe]

There are likely to be multiple domain specific types. I suggest that we do not try to add them in at this point. Time is probably even more difficult to specify than strings.

[lachlansneff]

I wouldn't necessarily call time domain-specific, but I will give you that it may be difficult to specify. I couldn't imagine the complexity of including things like time zones and whatnot.

[Ms2ger]

FTR, JS is gaining a bunch of new date/time APIs: https://tc39.es/proposal-temporal/

[J0eCool]

My understanding of interface types is that its chief advantage is being able to coordinate across modules without coordinating on the representation/implementation of the types in question.

Leaving time opaque at the IT layer would allow us to seamlessly update individual modules come 2554 without worrying about compatibility, for example.

[anarchodin]

Time is a complex beast, and fixed-precision seconds-since-epoch timestamps are not by a long shot the only representation needed. See, as an example, the US Library of Congress's Extended Date-Time Format, which has since been made part of ISO 8601. I'd also suggest reading The Long, Painful History of Time for an overview of the issues and an alternative representation (which still doesn't account for the added complexities of EDTF).

All of which is to say that I think defining the datatype and encoding for time is more of an API question than a fundamental type.