Simon Slavin wrote:
>
> Perhaps you might want to take the source code for the existing julian
> date function and modify it.
>
If the system in question is online, perhaps the following URL (or one
like it) could be fetched periodically and used to help synchronize said
custom extension:
On 5/22/2013 6:48 PM, Stephan Buchert wrote:
It seems that I failed to make the point clear:
On June 30, 2012 the 86401st second happened in the real world
I think you mean "a second was artificially added by some, but not all
or even most, people to some, but not all or even most, calendar
On 22 May 2013, at 11:48pm, Stephan Buchert wrote:
> However, Sqlite's julianday seems to have limitations because it returns
> NULL for times that fall in leap seconds (in addition, it is off by
> presently about 1 min from the Julian Day that is used in astronomy).
> Perhaps the reason is that
It seems that I failed to make the point clear:
On June 30, 2012 the 86401st second happened in the real world, it was
working time in parts of the US. In this second there were financial
transactions, photos were taken, sensors delivered data, etc etc, events
that users might want to insert into
On 5/22/2013 5:28 PM, Stephan Buchert wrote:
Sqlite's julianday in the leap second seems to be NULL:
sqlite> select julianday('2012-06-30T23:59:60')*86400;
So is julianday('foobar'). '2012-06-30T23:59:60' is simply not a
syntactically valid time string, per
http://www.sqlite.org/lang_datefun
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-0
> The time available in computers (smartphones etc) is normally UTC and a
> local time offset, which is sufficient for almost all times, but not
> quite all. On average every 18 months leap seconds are inserted. Events
> during these leap seconds cannot be unambiguously timestamped by a
> represen
On Wed, May 22, 2013 at 10:05 AM, Stephan Buchert wrote:
> 1) do nothing, or maybe just document more clearly, that the julianday
> in Sqlite, for date/time input in UTC, returns JD(UTC) in IAU
> terminology, which, for example, does give time differences (or nr of
> days elapsed since epoch) igno
Sqlite provides in its SQL the julianday function, which can serve as a
timestamp with a good resolution (millisecs, double precision
floating point numbers are used) and for times way back into the past
and far into the future. However, as presently implemented, the
function does not really retur
9 matches
Mail list logo
