This page is part of the web mail archives of SRFI 19 from before July 7th, 2015. The new archives for SRFI 19 contain all messages, not just those from before July 7th, 2015.
>> Making time a distinct datatype, instead a number, has > plusses & minusses. > I have mixed feelings. > - Plusses > Increased error detection > Can represent time as pair of ints -- second & subsecond > precision. > ...which allows hiding leap seconds in the subsecond part, a la > Kuhn's proposal. > > - Minusses > Cannot use arithmetic ops to do time calculations -- very annoying > Must cons to generate a time; not low overhead. > > The second minus -- that you must allocate storage to get a > time stamp -- is > not *so* important, because you can always have an alternate, > purpose-designed > low-overhead interface, of the TIME+TICKS variety, which can > return what > Markus Kuhn calls "process" time. > > However, I'm not so comfortable with the first minus. Is > there to be some > form of conversion between time & seconds? > > I suggest there are enough open issues to warrant extending > the discussion > period of this SRFI. Time is tricky. > -Olin > I don't have time to think through all of Olin's suggestions and corrections. I've started looking at Kuhn's page. I do have time->seconds, and seconds->time procedures, with implementation specific epochs, in the proposal. Kuhn makes a strong argument for distinguishing between TIME_TAI (essentially, time, including leap seconds) and TIME_MONOTONIC (essentially, the number of seconds since some epoch)--e.g., 'after 10 seconds' means different things. (And, if these are added, then a TIME_PROCESS and TIME_THREAD (in Kuhn's terms) make sense again.) I'll probably add a TIME_MORONIC type, too, to capture all of the math errors I keep leaving in :) I'll try to make an issues list in the next few days. If people would like to send me suggestions for the list, please do so directly or via the mail list as a whole. -- Will (with apologies to Olin for triplicates)