Re: [Chicken-users] (current-seconds) returning negative values

[Valentyn Kamyshenko]

On Jan 11, 2004, at 11:36 PM, Felix Winkelmann wrote:

> Am Sun, 11 Jan 2004 22:58:31 -0800 hat Valentyn Kamyshenko 
> <address@hidden> geschrieben:
>
> > > Urgh. Indeed. I'll change `current-seconds' to return
> > > a floating-point number.
> > does it mean that it will not have a 1-sec resolution anymore?
>
> Dammit. I stumbled over that thing again. Yes, you're right, just
> changing it to a flonum won't help.
> In fact for comparisons, a negative value of `(current-seconds)'
> should still work. But that it's negative is still unsatisfying.
not always: I'm actually having troubles currently with the files 
changed before the critical date.

> > I would suggest to introduce a special function for time difference 
> > calculations instead, so that
> >    (time_diff (current-seconds) (file-modification-time "bla"))
> > would work properly.
> >
> > Basically, I think it would be preferable to treat output of 
> > functions like current-seconds as a special type (which may be the 
> > unsigned integer, but is in fact of the time_t type in unix).
>
> This may be the best solution. SRFI-18 already provides a 
> `current-time'
> procedure. We could change `file-...-time' (and perhaps some others)
> to return time objects instead of seconds, together with some basic
> operators (time+, time-, time>?, etc.) that can be used to perform
> arithmetic and comparisons.
>
> Would that be more satisfactory?

In my opinion - definitely, yes. And for me, personally, there will be 
no much troubles with the backward compatibility...

Regards,

        Valentyn.


> cheers,
> felix