True. However, SRFI 19 timespec objects are mutable, which I consider a Bad Thing. In addition, the source code for them is not isolated from the rest of SRFI 19. I've added some new language (in the johnwcowan/srfi-174 repo) to explain the limitations on using SRFI 19 to help implement SRFI 174.
Quoting from <https://srfi.schemers.org/srfi-19/srfi-19.html>:
---
A time object consists of three components:
* Time type, a symbol representing the time system representation used.
The constants TIME-TAI, TIME-UTC, TIME-MONOTONIC, TIME-THREAD,
TIME-PROCESS, and TIME-DURATION must be provided for these symbols.
Implementations should provide constants for time type extensions.
* Second, an integer representing the number of whole seconds from "the
epoch."
* Nanosecond, an integer of the number of nanoseconds in the fractional
portion. Although a time object has nanosecond precision, clocks may
have a lower resolution.
---
Although SRFI 19 mandates a ton of other stuff, the timespec object in
SRFI 174 seems to be an exact duplicate of a SRFI 19 time object. SRFI
19 just has an extra time type field.
Also procedures:
* make-time type nanosecond second -> time
* time? object -> boolean
* time-nanosecond time -> integer
* time-second time -> integer