Excellent point. I'm switching to a new computer so it'll take me a while to fix this: not all the new machine's marbles are available yet. I never intended timespecs to be mutable.
The SRFI should probably say that it is an error to mutate a timespec
after making one with the `timespec` procedure.
Timespecs implemented as cons cells are trivially mutable, but that can
cause interoperability problems with implementations that have timespecs
as opaque objects. We'd have to specify portable `timespec-set-seconds!`
and `timespec-set-nanoseconds!` procedures, and that's hardly worth the
effort as it's just as easy to make a new timespec object. Immutable
values also tend to have less gotchas in general (hashing, aliasing, etc.)