On Tue, Nov 8, 2016 at 11:24 PM, George Neuner <gneun...@comcast.net> 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 maybe that's not a correct assumption.) At
>> any rate, I think your original example demonstrates a problem with
>> seconds->date on Windows.
>>
>
> Sorry, that was confusing. What I meant to say was: the results are
> correct (given the treatment of the original date fields as UTC and the
> treatment of the resulting seconds as local), but based on your original
> post, I don't think they're the results you were after. But I'm not certain
> of that.
>
> - Jon
>
>
> What I'm trying to do is the following:
>
> - I'm given 2 datetimes as iso8601 YYYY-MM-DD HH:MM strings, and a time
> zone offset
> - create UTC datetimes from the strings and tz
> - query a database returning records between the 2 UTC datetimes
>
> OK that was pretty easy. I believe I need to get [or look up somehow] a
> separate tz for each date string because the range may span both standard
> and daylight time, but at least I can get this far.
>
> Now the hard part:
>
> - I need to turn the UTC datetimes on all the results back into local
> times with the right time zone
>
> This part is driving me nuts. Nothing seems to work exactly right.
> (seconds->date ... #T) seems to get the numbers right, but not always the
> timezone,
>
Yeah, and this is because you're running into an actual bug that only
affects Windows. I think it's a very simple matter to fix, but since it
only affects Windows, and I don't have a Windows machine, I can't verify
that.
> and in any case it is limited to the local timezone of the machine -
> useless if local *is* UTC, and since I can't specify an arbitrary timezone,
> I can't use it in a server side application.
>
Right -- and this is something that Gregor can help with. If you have UTC
datetimes, you can first translate these from date* instances to Gregor
moments, using 0 as the time zone offset. Then, you can use
`adjust-timezone` to give you a new moment instance that represents the
same point in time but with whatever offset you specify.
That probably sounds a bit overly complicated. The db library doesn't
directly support Gregor, which is why you would need to translate from one
representation to another:
```
(require racket/date
racket/match
gregor)
(define (date*->moment/offset d offset)
(match d
[(date* sec min hr day mon yr _ _ _ off ns _)
(adjust-timezone (moment yr mon day hr min sec ns #:tz off)
offset)]))
;; ex:
(date*->moment/offset (current-date) -18000)
```
This (or Ryan's approach, which uses SRFI 19 instead of Gregor) will work
fine if you only need UTC offsets. If, however, you need to work with
proper time zones (like America/New_York) -- which you will if you need to
do any date arithmetic on localized dates -- then you'll want to stick with
Gregor.
About the Gregor documentation, it would be great if you could drop me a
note with suggestions for improving it.
- Jon
--
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.
