On Fri, Sep 5, 2014 at 6:19 PM, Alex Vondrak <ajvond...@gmail.com> wrote:
> I also realize now that this "date" vs "datetime" distinction was what Jon
> was suggesting, whereas I thought he was talking about "have one version
> normalize to local time, have the other normalize to GMT" (like
> Date.current & Date.today in Rails).
>
Yes, that's indeed what I meant. Not sure if another tuple would be
clearer, or if a strongly documented convention is enough..
Fair enough. I think changing timezones is less of a deal-breaker than
> `ymd>timestamp` & `timestamp>ymd` not being inverses of each other (without
> intervening GMT conversion), though.
>
Well, changing `ymd>timestamp` to assume a locale timezone makes them
inverse only if the orginal timestamp was in the local timezone (ie breaks
for GMT timestamp or any other timezone). The advantage would be that most
of the other words in the vocab return timestamps in the local timezone so
it would work most of the time.
> I guess a solution to both problems could be just having more robust
> parsing that could translate strings with GMT offsets. Many RFCs abound
> with date formats.
>
We have `timestamp>rfc3339` and `rfc3339>timestamp` which support
timezones. The strings look like "2014-09-05T01:00:00+02:00"
Cheers,
Jon
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
