Myk Melez <[EMAIL PROTECTED]> wrote:
> I noticed today that JavaScript Date values (the number of
> milliseconds since the Unix epoch) degrade to second precision when
> converted to Julian date values and back using naive SQLite date/time
> function calls, for example:
>
> sqlite> SELECT strftime('%s', julianday(1219441430151/1000,
> 'unixepoch')) * 1000;
> 1219441430000
>
> I suppose this is because "Unix has no tradition of directly
> representing non-integer Unix time numbers as binary fractions."
No. 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.
Second, strftime('%s') is documented as printing the number of seconds.
Even if its parameter is a fraction, its output is always an integer
(or, to be precise, a string of digits convertible to an integer).
You can convert "seconds since Unix epoch" to Julian day like this:
J = U / 86400.0 + 2440587.5
86400 is the number of seconds in a day. 2440587.5 is the result of
julianday('1970-01-01') - the difference between Unix epoch and Julian
epoch.
Igor Tandetnik
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
