On Mon, Oct 3, 2022 at 10:59 AM Marc Nieper-Wißkirchen < [email protected]> wrote:
> I would make the time object opaque and of a disjoint type to catch > typing errors. > Absolutely. > I don't understand the logic behind the design choices of SRFI 19 > fully. For the purpose of SRFI 226, it is specifying much more than > what is needed (and the split between seconds and nanoseconds is > arbitrary in view of this SRFI). But we probably want more than just a > duration but also an absolute time to specify a concrete time in the > future. > Indeed, SRFI 19 specifies more than is needed for any given use case, but I think that it is much better than having many individually tailored types of absolute time and duration objects. SRFI 19 was there first (so it is already widespread) and is sufficiently general (note that by "SRFI 19" I mean the data structure, not all the conversions) to cover all the cases. I want to use it everywhere in R7RS-large. > in SRFI 19, > a time duration is also a time. I don't want to follow this because it > is like comparing apples with pears. > That troubled me too at first, until I realized that a duration can be viewed an absolute time whose epoch is context-dependent, rather than itself being absolute as with the other SRFI 19 epoch settings.
