Yes, the documentation gives there a hint that also the Sqlite time
functions have the usual problems with the leap seconds.
A specific example:
sqlite> select julianday('2012-06-30T23:59:59')*86400;
212207860799.0
The up to now most recent leap second then was from 2012-06-30T23:59:60
to 2012-06-30T23:59:60.999 ..., i.e. June 30, 2012 had 86401 seconds.
Sqlite's julianday in the leap second seems to be NULL:
sqlite> select julianday('2012-06-30T23:59:60')*86400;
sqlite> select julianday('2012-07-01T00:00:00')*86400;
212207860800.0
In reality two seconds elapsed between 2012-06-30T23:59:59
and 2012-07-01T00:00:00.
For comparison, the mktime function of the standard library in my computer
(CET) returns
1341093599, 1341093600, 1341093600 for the
times 2012-06-30T23:59:59, 2012-06-30T23:59:60, and 2012-07-31T00:00:00,
respectively. Neither correct, but perhaps better than Sqlite's NULL for
the leap second time.
It has been suggested to stop inserting leap seconds in order to avoid
these problems with computerized time stamps. The committees in charge have
deferred a decision on the leap seconds until 2015, so likely there will be
at least 1-2 more of them.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
