On Fri, Feb 19, 2016 at 6:34 PM, Jos Koot <jos.k...@gmail.com> wrote:
> Thanks very much for your reply. > Reflecting your post it now is clear to me that the (decimal) order of > magnitude of the year > (seconds->date (sub1 (expt 2 50))) should be around 7 or 8 (setting > second 0 to "Thu, 01 Jan 1970 01:00:00 +0100"). > How do you know the year should be (exactly) 35680317? > Jos > It comes out that way on my system (OS X): > (seconds->date (sub1 (expt 2 50))) (date* 3 57 13 25 9 35680317 2 267 #f -18000 0 "EST") And I double-checked it with gregor (which doesn't use the OS for computing dates and times): > (require gregor) > (posix->datetime (sub1 (expt 2 50))) #<datetime 35680317-09-25T18:57:03> Note the difference in the hours field between the two answers is the result of using local time for the former and UTC for the latter. If I pass the additional flag to seconds->date: > (seconds->date (sub1 (expt 2 50)) #f) (date* 3 57 18 25 9 35680317 2 267 #f 0 0 "UTC") ... the results are the same. -Jon > > > ------------------------------ > *From:* Jon Zeppieri [mailto:zeppi...@gmail.com] > *Sent:* viernes, 19 de febrero de 2016 23:31 > *To:* Jos Koot > *Cc:* Racket Users > *Subject:* Re: [racket-users] second->date > > I'm not especially familiar with the code in question, but it looks to me > like some time-handling code in fun.c assumes 32-bit values. I'm referring > to this: [ > https://github.com/racket/racket/blob/50db01bf2c7c57fd5c7c662307d517ce2c29c279/racket/src/racket/src/fun.c#L9981]. > > > On a 64-bit system, mzlonglong should be 64 bits wide, I think, but the > code here seems to assume 32 bits. > > Again, I'm really not very familiar with this code, though. > > (By the way, the date* you get back from (sub1 (expt 2 50)) isn't correct. > The year should be 35680317.) > > -Jon > > > > On Fri, Feb 19, 2016 at 4:49 PM, Jos Koot <jos.k...@gmail.com> wrote: > >> The following surprises me: >> >> > (seconds->date (sub1 (expt 2 40))) >> seconds->date: integer is out-of-range >> integer: 1099511627775 >> Nevertheless I can go further on in time: >> >> > (seconds->date (sub1 (expt 2 50))) >> #(struct:date* >> 40 >> 5 >> 11 >> 23 >> 9 >> 22520 >> 1 >> 266 >> #t >> 7200 >> 0 >> "Romance Daylight Time") >> >> But when I go too far in future, I find myself in the past: >> >> > (seconds->date (sub1 (expt 2 62))) >> #(struct:date* >> 59 >> 59 >> 0 >> 1 >> 1 >> 1970 ---> the future seems to be in the past >> 4 >> 0 >> #f >> 3600 >> 0 >> "Romance Standard Time") >> >> This in the REPL of DrRacket (64 bits, Windows 7) >> Anyone an idea what is happening here? >> Things go well with seconds < (expt 2 31) >> Thanks, Jos >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Racket Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to racket-users+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
