Re: [racket-users] problems with sql-timestamp and date*

2015-08-22 Thread Ryan Culpepper
On 08/22/2015 06:18 PM, George Neuner wrote: On 8/22/2015 5:50 PM, Jon Zeppieri wrote: On Sat, Aug 22, 2015 at 4:36 PM, George Neuner wrote: > > The latter code using date works properly (modulo the time zone field) and > gives consistent results, but the former using date* gives inconsistent >

Re: [racket-users] problems with sql-timestamp and date*

2015-08-22 Thread George Neuner
On 8/22/2015 5:50 PM, Jon Zeppieri wrote: On Sat, Aug 22, 2015 at 4:36 PM, George Neuner wrote: > > The latter code using date works properly (modulo the time zone field) and > gives consistent results, but the former using date* gives inconsistent > results. > > E.g.,: with timezone = -5 > > =

Re: [racket-users] problems with sql-timestamp and date*

2015-08-22 Thread Jon Zeppieri
On Sat, Aug 22, 2015 at 5:50 PM, Jon Zeppieri wrote: > On Sat, Aug 22, 2015 at 4:36 PM, George Neuner wrote: [Sorry, I bungled the this part of the email.] > Maybe I'm confused, but my understanding > is that the database timestamp is in UTC, and you want a date* > representing the same point i

Re: [racket-users] problems with sql-timestamp and date*

2015-08-22 Thread Jon Zeppieri
On Sat, Aug 22, 2015 at 4:36 PM, George Neuner wrote: > > The latter code using date works properly (modulo the time zone field) and > gives consistent results, but the former using date* gives inconsistent > results. > > E.g.,: with timezone = -5 > > => expires #(struct:sql-timestamp 2015 8 22 2

Re: [racket-users] problems with sql-timestamp and date*

2015-08-22 Thread George Neuner
On 8/22/2015 4:02 PM, Jon Zeppieri wrote: Where exactly do you see sql-timestamp->srfi-date failing? In your examples, what I'm seeing is incorrect translation from UTC to UTC-4, but I don't see where the translation from sql-timestamp to date* is going wrong. Could you point to exactly where you

Re: [racket-users] problems with sql-timestamp and date*

2015-08-22 Thread George Neuner
A little more experimenting shows that changing *date*->seconds* to *date->seconds* (no asterisk) in (seconds->date (+ (date*->seconds ts #f) (* timezone 60 60)) #f)) guarantees the time offset always is correct wrt the original UTC time. So it seems that *(seconds->

Re: [racket-users] problems with sql-timestamp and date*

2015-08-22 Thread Jon Zeppieri
On Sat, Aug 22, 2015 at 4:02 PM, Jon Zeppieri wrote: > > > (require gregor) > (require racket/match) > > (define (sql-timestamp->moment t) > (match-define (sql-timestamp y mo d h mi s n tz) t) > > (moment y mo d h mi s n #:tz (or tz 0))) Actually, a sql-timestamp with a #f tz means that the t

Re: [racket-users] problems with sql-timestamp and date*

2015-08-22 Thread Jon Zeppieri
Where exactly do you see sql-timestamp->srfi-date failing? In your examples, what I'm seeing is incorrect translation from UTC to UTC-4, but I don't see where the translation from sql-timestamp to date* is going wrong. Could you point to exactly where you see the problem? As far as offsetting time

Re: [racket-users] problems with sql-timestamp and date*

2015-08-22 Thread George Neuner
Ok, reading the docs more carefully, I realized that *seconds->date* takes a boolean and not a time zone offset, but that doesn't explain why *sql-timestamp->srfi-date* is not working properly. I'm now offsetting the time with (seconds->date (+ (date*->seconds ts #f) (* timezone

[racket-users] problems with sql-timestamp and date*

2015-08-22 Thread George Neuner
Hi all, Got a wierd problem handling dates. I am retrieving a UTC timestamp from a Postgresql (9.3.9) database, converting it to a date* and then offsetting to a (variable) time zone. eliding a lot of unrelated code: : (require (only-in srfi/19 date->string)