On Thu, Nov 10, 2016 at 10:52 AM, Jon Zeppieri wrote:
>
>
> On Thu, Nov 10, 2016 at 10:45 AM, Jon Zeppieri wrote:
>
>>
>>
>> On Thu, Nov 10, 2016 at 4:52 AM, George Neuner
>> wrote:
>>
>>>
>>> On 11/9/2016 2:18 AM, Ryan Culpepper wrote:
>>
>>
>>
>>>
>>> Postgresql follows the ISO convention bec
On Thu, Nov 10, 2016 at 10:45 AM, Jon Zeppieri wrote:
>
>
> On Thu, Nov 10, 2016 at 4:52 AM, George Neuner
> wrote:
>
>>
>> On 11/9/2016 2:18 AM, Ryan Culpepper wrote:
>
>
>
>>
>> Postgresql follows the ISO convention because the SQL standard follow the
>> ISO convention. Ask Postgresql for "+5
On Thu, Nov 10, 2016 at 4:52 AM, George Neuner wrote:
>
> On 11/9/2016 2:18 AM, Ryan Culpepper wrote:
>
>>
>> Another option is to let PostgreSQL do it for you using AT TIME ZONE (or
>> the timezone function):
>>
>> select ('2016-11-09 01:23:00Z'::timestamptz)
>> at time zone 'us/eastern';
On 11/9/2016 2:18 AM, Ryan Culpepper wrote:
Another option is to let PostgreSQL do it for you using AT TIME ZONE
(or the timezone function):
select ('2016-11-09 01:23:00Z'::timestamptz)
at time zone 'us/eastern';
=> 2016-11-08 20:23:00
But beware that PostgreSQL interprets numerical
Hi Ryan,
On 11/9/2016 2:18 AM, Ryan Culpepper wrote:
Does the following do what you want?
(require srfi/19)
;; date-at-tz : Date Integer -> Date
;; Returns date of equivalent instant in given timezone.
(define (date-at-tz d tz)
(let ([t (date->time-utc d)])
(time-utc->date t
Thanks very much for tracking down the problem! I've pushed a repair.
At Tue, 8 Nov 2016 17:31:53 -0500, Jon Zeppieri wrote:
> I think Robby is right and the problem is here:
> https://github.com/racket/racket/blob/4ce947da74d09abc9cda10a14e7407cda9386a44/
> racket/src/racket/src/fun.c#L9876
>
>
On Tue, Nov 8, 2016 at 11:24 PM, George Neuner wrote:
> Hi Jon,
>
> On 11/8/2016 6:28 PM, Jon Zeppieri wrote:
>
>
> George, these are not correct results. The UTC offset is correct, but the
>> time fields are not -- under the assumption that you're trying to
>> round-trip them unchanged. (But may
On 11/08/2016 11:24 PM, George Neuner wrote:
[...]
- I need to turn the UTC datetimes on all the results back into local
times with the right time zone
Does the following do what you want?
(require srfi/19)
;; date-at-tz : Date Integer -> Date
;; Returns date of equivalent instant in g
Hi Jon,
On 11/8/2016 6:28 PM, Jon Zeppieri wrote:
George, these are not correct results. The UTC offset is correct,
but the time fields are not -- under the assumption that you're
trying to round-trip them unchanged. (But maybe that's not a
correct assumption.) At any rate, I th
On Tue, Nov 8, 2016 at 6:26 PM, Jon Zeppieri wrote:
>
>
> On Tue, Nov 8, 2016 at 6:18 PM, George Neuner
> wrote:
>
>>
>> On 11/8/2016 2:29 PM, Robby Findler wrote:
>>
>>> find-seconds returns a number, not a date? Maybe seconds->date is the
>>> culprit here?
>>>
>>> Robby
>>>
>>
>> Spoke too soo
On Tue, Nov 8, 2016 at 6:18 PM, George Neuner wrote:
>
> On 11/8/2016 2:29 PM, Robby Findler wrote:
>
>> find-seconds returns a number, not a date? Maybe seconds->date is the
>> culprit here?
>>
>> Robby
>>
>
> Spoke too soon. 1 combination gets it right: (seconds->date
> (find-seconds ... #F)
On 11/8/2016 2:29 PM, Robby Findler wrote:
find-seconds returns a number, not a date? Maybe seconds->date is the
culprit here?
Robby
Spoke too soon. 1 combination gets it right: (seconds->date
(find-seconds ... #F) #T).
Note that (for me) Nov 6 should be DST [until 2AM], but Nov 7 shoul
On 11/8/2016 2:29 PM, Robby Findler wrote:
find-seconds returns a number, not a date? Maybe seconds->date is the
culprit here?
Robby
Possibly. But both functions take an optional local-time? parameter.
The various combinations don't seem to affect the time zone wrt daylight
saving.
Geor
I think Robby is right and the problem is here:
https://github.com/racket/racket/blob/4ce947da74d09abc9cda10a14e7407cda9386a44/racket/src/racket/src/fun.c#L9876
Well, that and the next line. There's only a `return 1;` for the case where
the given day-of-month is less than the DST change's day-of-m
find-seconds returns a number, not a date? Maybe seconds->date is the
culprit here?
Robby
On Tue, Nov 8, 2016 at 12:32 PM, George Neuner wrote:
>
> Racket 6.6 on Windows 7.
>
> find-seconds is getting the time zone wrong when local-time? is #t.
> Somehow it is in daylight saving all through Nove
Racket 6.6 on Windows 7.
find-seconds is getting the time zone wrong when local-time? is #t.
Somehow it is in daylight saving all through November.
When local-time? is #f (UTC) the time zone and hour offset are
correct. [At least for "fall back", didn't check "spring ahead"]
(for* [(m '(11
16 matches
Mail list logo
