The documentation is certainly inconsistent: `current-seconds' claims to platform-specific, `current-inexact-milliseconds' claims to be since 1970, and `seconds->date' claims to work with both.
I think the right documentation repair is that `current-seconds' results are actually portable, and ditto for `file-or-directory-modify-seconds'. I'll double-check and fix the docs. I'll also look into the leap-second issue. I worry about the potential to break old code if I change the contract, but probably its ok in this case (i.e., code that breaks would have to be strange). At Tue, 19 Jun 2012 15:19:16 +0200, Pierpaolo Bernardi wrote: > On Sat, Jun 16, 2012 at 6:23 AM, Matthew Flatt <mfl...@cs.utah.edu> wrote: > > I'm confused by the question. Maybe you have and old version where > 'seconds->date' accepts only integers? The current version accepts a real, > and > so fractional seconds can be in the argument to 'seconds->date'. > > BTW, related to seconds->date, but not to the original question. From > seconds->date documentation: > > "The value returned by current-seconds or > file-or-directory-modify-seconds is not portable among platforms. > Convert a time in seconds using seconds->date when portability is > needed." > > Making this value portable only requires an addition, so why not make > it portable? > > and: "For the second field, values of 60 and 61 are for unusual, but > possible for leap-seconds." > > AFAIK, there cannot be more than one leap-second in a minute > (actually, more than one in a month), so I believe the correct range > should be 0..60. (I also believe there's a typo in the quoted > sentence). > > Cheers > P. > ____________________ > Racket Users list: > http://lists.racket-lang.org/users ____________________ Racket Users list: http://lists.racket-lang.org/users
