RE: [racket-users] second->date
Thanks to both Jon and Matthew. BTW, Jon, my mailer (microsoft outlook) sometimes does strange things with the fonts :) Jos -Original Message- From: Matthew Flatt [mailto:mfl...@cs.utah.edu] Sent: sábado, 20 de febrero de 2016 2:58 To: Jos Koot; Jon Zeppieri Cc: Racket Users Subject: Re: [racket-users] second->date There was an overflow problem in the part that tries to prepare a 64-bit value to put into the 32-bit halves of `FILETIME`. I've pushed a repair. Thanks for the report and help! At Fri, 19 Feb 2016 18:06:55 -0500, Jon Zeppieri wrote: > Er, no. Disregard that. That'll teach me to talk about the Windows API when > I know nothing about it. Apparently, the FILETIME type is divided into two > 32-bit values. > > At any rate, there is a bug, but I don't know where it is. > > -Jon > > > On Fri, Feb 19, 2016 at 5:31 PM, Jon Zeppieri wrote: > > > 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/50db01bf2c7c57fd5c7c662307d517ce2c29c2 79/ > 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 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. -- 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.
Re: [racket-users] second->date
There was an overflow problem in the part that tries to prepare a 64-bit value to put into the 32-bit halves of `FILETIME`. I've pushed a repair. Thanks for the report and help! At Fri, 19 Feb 2016 18:06:55 -0500, Jon Zeppieri wrote: > Er, no. Disregard that. That'll teach me to talk about the Windows API when > I know nothing about it. Apparently, the FILETIME type is divided into two > 32-bit values. > > At any rate, there is a bug, but I don't know where it is. > > -Jon > > > On Fri, Feb 19, 2016 at 5:31 PM, Jon Zeppieri wrote: > > > 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 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. -- 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.
Re: [racket-users] second->date
On Fri, Feb 19, 2016 at 6:34 PM, Jos Koot 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))) # 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 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.
RE: [racket-users] second->date
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 _ 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/50db01bf2c7c57fd5c7c662307d517ce2c29c 279/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 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.
Re: [racket-users] second->date
Er, no. Disregard that. That'll teach me to talk about the Windows API when I know nothing about it. Apparently, the FILETIME type is divided into two 32-bit values. At any rate, there is a bug, but I don't know where it is. -Jon On Fri, Feb 19, 2016 at 5:31 PM, Jon Zeppieri wrote: > 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 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.
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 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.
[racket-users] second->date
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.
