Re: [racket-users] second->date

[Matthew Flatt]

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

[Jon Zeppieri]

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)))
#

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.

RE: [racket-users] second->date

[Jos Koot]

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

Re: [racket-users] second->date

[Jon Zeppieri]

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

[Jon Zeppieri]

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

[Jos Koot]

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.