Re: Re[2]: [sqlite] Bug in the precision of strftime function
--- Slava Tutushkin <[EMAIL PROTECTED]> wrote:
>
> MJ> -4713-11-24 GC, which is -4712-01-01 JC" so datetime(0) does correctly
> MJ> convert Julian Day 0 to a (proleptic) Gregorian date but not to a Julian
> MJ> Date as (I think) I thought. That'll teach me to post follow-ups when
>
> I see no problem here while, because it does not matters, what day
> julianday() references to,
> all we need - stable pivot point. I'm using REAL julianday() value for
> internal storage in
> sqlite only, after reading from DB I'm converting to boost::ptime.
> But strftime was not returning precise values sometimes.
>
> My post was about floating point problems with the milliseconds in the
> strftime. I was
> investigated it a little bit longer, and found out that even the query
> "select strftime('%Y-%m-%d %H:%M:%f', '2006-09-24T10:50:26.046');"
> is returning 2006-09-24 10:50:26.045.
>
> Anyway, somebody (thank you!) posted a patch in the ticket, solving this
> problem. I was not
> tested it for now, but seems it looks ok.
> URL for ticket is:
> http://www.sqlite.org/cvstrac/tktview?tn=1991
I had missed the boundary case for 59.+ seconds.
Please use the latest version of the patch.
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
Re[2]: [sqlite] Bug in the precision of strftime function
MJ> -4713-11-24 GC, which is -4712-01-01 JC" so datetime(0) does correctly
MJ> convert Julian Day 0 to a (proleptic) Gregorian date but not to a Julian
MJ> Date as (I think) I thought. That'll teach me to post follow-ups when
I see no problem here while, because it does not matters, what day julianday()
references to, all we need - stable pivot point. I'm using REAL julianday()
value for internal storage in sqlite only, after reading from DB I'm converting
to boost::ptime.
But strftime was not returning precise values sometimes.
My post was about floating point problems with the milliseconds in the
strftime. I was investigated it a little bit longer, and found out that even
the query
"select strftime('%Y-%m-%d %H:%M:%f', '2006-09-24T10:50:26.046');"
is returning 2006-09-24 10:50:26.045.
Anyway, somebody (thank you!) posted a patch in the ticket, solving this
problem. I was not tested it for now, but seems it looks ok.
URL for ticket is:
http://www.sqlite.org/cvstrac/tktview?tn=1991
--
Slava Tutushkin, http://aloner.ru
mailto:[EMAIL PROTECTED]
ICQ: 55463183
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
