Brandon Fosdick wrote:
> sqlite> select date('1220302462','unixepoch');
> sqlite> select date('1220249914','unixepoch');
Unix times contain no time zone information (they are relative to an
epoch in the UTC time zone), and SQLite's date/time functions return
Igor Tandetnik wrote:
> You have two problems. First, 1219441430151/1000 is done as C-style
> integer truncating division, so you are losing your fractions right
> there. Try
> select 1219441430151/1000, 1219441430151/1000.0;
> and see the difference.
Is "REAL" the recommended declared type for a column storing only Julian
date values that generally include a fractional time portion?
sqlite-users mailing list
since the Unix epoch) degrade to second precision when converted to
Julian date values and back using naive SQLite date/time function calls,
sqlite> SELECT strftime('%s', julianday(1219441430151/1000,
Joanne Pham wrote:
> I have read online document regarding SQLITE3 data type and below is list of
> these datatypes:
> * TEXT
> * NUMERIC
> * INTEGER
> * REAL
> * NONE
> But just now I found out SQLITE3 has bigint and int as another datatype.
Scott Hess wrote:
> It's not entirely clear that the fts search syntax should aim to hew too
> closely to consumer-oriented search syntax.
Indeed, I would expect the FTS search syntax to optimize for the machine
model, while the user-facing syntax optimizes for human
comprehensibility, and the
Scott Hess wrote:
The  status is ... pending, sorry :-(. But it is more along the
lines of adding stuff to ICU rather than adding ICU-less stuff to
SQLite, so it sounds like that is not relevant to what you're doing.
Thanks for the info. Indeed, enhancements to ICU don't
I'm working to enable FTS3 in the next version of Firefox  so that
extenders can take advantage of it, although Firefox itself isn't using
it for the next release.
Given Firefox's international audience, it would be useful for FTS3 to
support Unicode. We currently do this for
Mail list logo