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

[felix]

On Sun, 11 Jan 2004 23:42:54 -0800, Valentyn Kamyshenko <address@hidden> 
wrote:

> 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...

Ok. Change of plan:

I was completely confused (as usual). If `current-seconds' (and `file- 
modification-time') return flonums,
we still have 2^53 bits of precision, assuming IEEE double
precision floats, which Chicken (on all supported platforms) uses.
So we have more than enough precision to handle bigger values.

I have changed `current-seconds' (library), `current-time',
`seconds->time', `time->seconds' (srfi-18), `file-modicfiation-time',
`seconds->local-time' and `seconds->utc-time' (posix) to
handle floating-point values. If we would have a native
`current-time' and time-comparison operations, a future SRFI-19
library could not be easily incorporated without either breaking
old code (the native time type would not be a SRFI-19 time type),
or by adding several ugly hooks which SRFI-19 could use.

So I think the best solution is to stay with seconds and
use Joerg's SRFI-19 library (as soon as I have it ready) for
more interesting stuff.


cheers,
felix