'scuse me....I was wrong (again)...I guess strftime does return an
integer....seems to me that belies the name as it's a mismatch to the unix
function.
select strftime('%s','now');
1317236583
But I think you may want:
strftime('%s','now','unixepoch','localtime');
That works with the default datetime() then when you select it.
sqlite> select datetime(strftime('%s','now'),'unixepoch','localtime');
2011-09-28 14:05:09
So...given that you actually stuck integers into your table I'm a bit surprised
that it took longer.
Michael D. Black
Senior Scientist
NG Information Systems
Advanced Analytics Directorate
________________________________
From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] on
behalf of Roger Andersson [r...@telia.com]
Sent: Wednesday, September 28, 2011 1:52 PM
To: sqlite-users@sqlite.org
Subject: EXT :Re: [sqlite] speeding up FTS4
On 09/28/11 20:14, Black, Michael (IS) wrote:
> strftime returns a text representation. So you didn't really change anything.
>
> You need to use juliandays() as I said.
>
>
> And you want a REAL number...not integer...though SQLite doesn't really care
> what you call it. It's more for your own reference.
>
Assuming that second resolution is sufficient.
Would
UPDATE table SET new_column = cast(strftime('%s', old_column) as integer);
make any difference?
/Roger
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
