__wasi_timestamp_t range (i.e. the year 2554 problem)

[AndrewScheidecker]

WASI timestamps (__wasi_timestamp_t) are currently encoded as an unsigned 64-bit integer number of nanoseconds since the Unix epoch. This gives a range of ~584 years, which is likely beyond the useful life of WASI, but much less range than modern OSes support:

• On 64-bit Linux and MacOS: time_t is 64-bit and thus timespec can represent a range of 584 billion years with nanosecond precision
• On Windows: FILETIME is 64-bit, and can represent a range of 58,400 years with 100 nanosecond precision

I doubt WASI-as-we-know-it will still be around in 2554, but such limits have the potential to infect software for a long time.

The simplest way (as far as the API is concerned) would be to just use a 128-bit integer. That's passing on the complexity of emulating 128-bit integers to hosts and users, though.

The way that seems most practical to me is to make clock_time_get return a timespec-like structure that factors the timestamp into a seconds i64 and a nanoseconds i32.

[sunfishcode]

I agree; switching to a timespec-like structure, with i64 (unsigned) seconds and i32 (unsigned) nanoseconds sounds more practical than a 128-bit integer, because a 128-bit integers would require programs that just want the number of seconds to do a 128-bit division.

[codefromthecrypt]

fwiw I don't agree with this change, as I don't think it optimizes for wasm as it exists. Currently, the only REC version of wasm-core is 1.0 and it has a 64bit numeric type which can be used as a stack value or a single read instruction. The former design was cheaper and more aligned with this. Also a single number is easier to get right than two, especially in the case of negative epoch. A common bug is not knowing whether to match signs with the fraction part, and this problem doesn't exist when there's only one value.

Knowing 2.0 isn't out of draft, yet, and the whole model itself is in flux, it seems speculative that this incarnation will last 500 years give or take. I recommend we revert this, as the former design wasn't well defended. However, I'm not going to fight to the death over it either. I would like an "alternate designs" section that includes some of these points if we stick with this especially due to the rationale given for this change.

:peace:

[sunfishcode]

The repo does now use a plain u64 for the monotonic clock. Just as you say, it's fast and simple. When measuring elapsed time within a single run of a program, 584 years is plenty. And the monotonic clock is the one where this kind of speed and simplicity will matter most.

The wall clock is the one that now uses a seconds + nanoseconds struct, and I agree it's debatable whether that's really necessary. Preview2 itself surely won't be still in use by 2554. So the guess here is that perhaps a future WASI 1.0 has some remote chance of needing to represent a date like that. And if we think WASI 1.0 will want that, we should include it in preview2 too, because preview2 is intended to be a preview showing, as close as we can get today, what we hope WASI 1.0 will look like.

Also, the wall clock tends to be less performance-sensitive. You're typically not measuring nanosecond-scale elapsed times with the wall clock. You're typically printing a timestamp in a log, or displaying the current time to the user, or comparing with filesystem timestamps, or similar.

[codefromthecrypt]

I'm personally aware of the use cases, but thanks for clarifying aloud for others. it is interesting what your perspective is on the longevity of this work. This is exactly the stuff that should be in rationale somewhere.

[sunfishcode]

Good idea. I've now filed #28 to track adding this to the docs.