简而言之，有很多方法。然而：
存储时间的最有效方法是将其存储为整数。类型本身（除非列被定义为INTEGER PRIMARY KEY）实际上并不重要，因为SQLite对列类型非常灵活，几乎允许指定任何类型。
此外，SQLite，除了rowid列，或rowid列的别名，以及最近的如果表是Strict Table;则任何类型的值可以存储在任何类型的列中。
根据您的创建（注意，在SQLITE中，关键字是AUTOINCREMENT，而不是 * INCREMENT*，不建议使用该关键字，它可能不是必需的），请考虑以下内容。

DROP TABLE IF EXISTS settime;
CREATE TABLE IF NOT EXISTS settime (
    time INTEGER DEFAULT (strftime('%s','now')), 
    hints virtually_any_type_can_used_even_rumplestiltskin, 
    another_time virtually_any_type_can_used_even_rumplestiltskinm DEFAULT (strftime('%s','now'))
);

INSERT INTO settime (hints) VALUES('hint1');
INSERT INTO settime (hints) VALUES('hint2');
INSERT INTO settime (hints) VALUES('hint3');
INSERT INTO settime VALUES (randomblob(16),randomblob(16),randomblob(32));
SELECT *, datetime(time,'unixepoch') AS visualtime FROM settime;

DROP TABLE IF EXISTS settime; /* CLEANUP */

当通过SQLite工具（Navicat用于示例）运行时，输出显示：

输出可能看起来令人困惑，尤其是最后一行。最后一行显示您可以在任何列类型中存储任何类型（BLOB）（有关例外情况，请参见上文）。也就是说，随机生成的blob已存储在所有3列中。
而不是2列，时间和提示，第三列另一个_时间已被包括在内，这有一个荒谬的列类型，因为提示列。列类型用于证明该类型在名称方面并不太重要，并且在存储数据方面几乎没有影响。
您可能还注意到，在time和another_time列中都指定了DEFAULT。如果在插入行时没有提供值，它将存储当前时间（now），精确到秒。因此，前3个插入只为hints列提供一个值。

• 注意，对于一个整数，8个字节等于一个64位有符号数，足以科普精度低至毫秒的情况（但是注意，unixepoch修饰符期望精度处于第二级别）。因此，将值存储到毫秒是可行的，只是您必须除以1000来剥离毫秒，使用SQLite日期和时间函数以及unixepoch修饰符。

SELECT使用*（所有未隐藏的列），然后使用datetime(time,'unixepoch') AS visualtime添加派生列调用visualtime。该列是YYYY-MM-DD HH：MM：SS格式的日期和时间，即存储的整数值使用SQLite内置的datetime函数进行转换（而不是因为日期是以unix存储的，所以unixepoch修饰符会通知该函数）。
数字值更有效，它们占用的存储空间更少（最多8个字节），而日期作为字符串（如YYYY-MM-DD HH：MM：SS）至少占用19个字节。整数值需要较少的处理，比如在排序或比较值时。唯一的缺点是该值不容易被人类读取。
你可参考：-

[Data Types in SQLite][4],
[Date and Time Functions][4],
[SQLite Autoincrement][2] (also includes much about the **`rowid`** column),
[Built-In Scalar SQL Functions][4] (such as `RandomBlob`)