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
{{ message }}
This repository was archived by the owner on Aug 17, 2022. It is now read-only.
Repository navigation
This repository was archived by the owner on Aug 17, 2022. It is now read-only.
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.
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.
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.
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.
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.
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.
Activity
lukewagner commentedon Dec 4, 2020
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
timeto that language's idiomatic time value (e.g.,Datein JS). I don't know much about the subtleties of timestamp values, but what you wrote seems like a reasonable start. I see WASItime_getcurrently returnsu64s. 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 commentedon Dec 4, 2020
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 commentedon Dec 6, 2020
Another factor to consider: is a timestamp wallclock time or monotonic time? Go, for example, uses both in an adaptive fashion.
fgmccabe commentedon Dec 6, 2020
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 commentedon Dec 6, 2020
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 commentedon Dec 7, 2020
FTR, JS is gaining a bunch of new date/time APIs: https://tc39.es/proposal-temporal/
J0eCool commentedon Dec 8, 2020
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 commentedon Jan 6, 2021
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.