It's not that the values are too large, it's that srfi 19 represents them as bignums, which is not currently supported by sql-de-lite. However, they work as floats (they will be converted to integers before being passed to the database, due to the column type). Even on 32-bit systems, we fully support handling 53 bit integers in the database in this way.
The easiest way to do this is by calling exact->inexact on the result to force it to floating point. Such a small value need not be a flonum on 64-bit system, but it will still work correctly, and it's the easiest way to ensure it is not a bignum. You can confirm the value was stored as an integer by using the typeof() SQL function, e.g. select typeof(date) from foo; Or you can just store the UNIX timestamp obtained from the posix unit, which should be a lot easier ;) Jim On Jul 22, 2013, at 18:18, Matt Gushee <m...@gushee.net> wrote: > Hi, Kon-- > > On Mon, Jul 22, 2013 at 4:34 PM, Kon Lovett <konlov...@gmail.com> wrote: > >> Do you need the range a SRFI-19 datetime provides? Maybe an epoch based >> approach, like provided by the posix module. > > No, I don't need the range. In fact, my project is a lightweight > blogging platform, and the date-times in question are creation and > modification times for the content, which will normally be displayed > to site visitors--possibly in localized formats; and other values > having to do with authentication and sessions, which will normally be > invisible. So I think it is safe to assume that all values that will > ever be used will fall within a couple of decades beginning with 2013. > > I'm not sure if I need to use SRFI-19. For some reason I thought that > it would be preferable from the POV of localized formatting and time > zone conversions, but looking again at the docs it doesn't seem like > that is necessary. > > But I notice that the posix date/time functions work with values > representing seconds, much like the values that are not working for > me--except that in posix they are floats instead of integers. So maybe > they won't cause errors? I'll give that a try. > > -- > Matt Gushee > > _______________________________________________ > Chicken-users mailing list > Chicken-users@nongnu.org > https://lists.nongnu.org/mailman/listinfo/chicken-users _______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users