Oh! I see. Sorry for the confusion. I misunderstood what you're written.
Robby
On Fri, Feb 1, 2013 at 7:01 PM, Matthew Flatt wrote:
> `date->seconds' did not change; it still returns an exact integer.
>
> At Fri, 1 Feb 2013 18:57:57 -0600, Robby Findler wrote:
> > Does this mean that date->sec
`date->seconds' did not change; it still returns an exact integer.
At Fri, 1 Feb 2013 18:57:57 -0600, Robby Findler wrote:
> Does this mean that date->seconds always returns inexacts now? Or does it
> return inexacts only when it wouldn't be an integer?
>
> (I'm not excited about either possibili
Does this mean that date->seconds always returns inexacts now? Or does it
return inexacts only when it wouldn't be an integer?
(I'm not excited about either possibility but the second seems bad only if
you consider TR.)
Robby
On Fri, Feb 1, 2013 at 5:22 PM, Matthew Flatt wrote:
> At Wed, 30 J
At Wed, 30 Jan 2013 22:23:04 -0500, Asumu Takikawa wrote:
> On 2013-01-30 23:20:45 +0100, Pierpaolo Bernardi wrote:
> >Any reason not to define current-date in this way? there's a nanosecond
> >field there wanting to get into action.
>
> While we're on the subject, it's also weird that `da
On 2013-01-30 23:20:45 +0100, Pierpaolo Bernardi wrote:
>Any reason not to define current-date in this way? there's a nanosecond
>field there wanting to get into action.
While we're on the subject, it's also weird that `date->seconds` has a
contract accepting date? and so doesn't handle da
Hello,
current-date returns a time* struct wich has a granularity of 1 s.
Using (seconds->date (* #i1/1000 (current-inexact-milliseconds))) appears
to works better.
Any reason not to define current-date in this way? there's a nanosecond
field there wanting to get into action.
Cheers
P.
___
6 matches
Mail list logo
