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 see the problem?
Hi Jon,
I believe now I was mistaken about *sql-timestamp->srfi-date*.
Recompiling my project seems to have fixed that - I am now getting
completely consistent results from the conversion.
However, I am still confused by the difference between
(seconds->date
(+ (date*->seconds expires #f) (* timezone 60 60))
#f))
and
(seconds->date
(+ (date->seconds expires #f) (* timezone 60 60))
#f))
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 21 56 33 805346000 0)
=> expires #(struct:date* 33 56 21 22 8 2015 6 233 #f 0 805346000 "")
=> expires #(struct:date* 58 9 17 22 8 2015 6 233 #f 0 346000000 "UTC")
=> expires #(struct:sql-timestamp 2015 8 22 22 23 45 95751000 0)
=> expires #(struct:date* 45 23 22 22 8 2015 6 233 #f 0 95751000 "")
=> expires #(struct:date* 20 25 17 22 8 2015 6 233 #f 0 751000000 "UTC")
Recompiling does not fix this. It seems like *date*->seconds* and
*seconds->date* are not symmetric. However, *sql-timestamp->srfi-date
*produces a *date**, so I thought I should being using *date*->seconds*.
BTW: this is in 6.1.1 (forgot to mention that previously).
George
--
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.
