[egenix-users] DateTime error rounding seconds
mal at lemburg.com
Thu Apr 4 20:45:11 CEST 2002
"M.-A. Lemburg" wrote:
> > The real problem with it, is that str() returns the truncated date just
> > like repr(), and we are using str() to insert datetime fields. If you
> > create a DateTime object for 03:04:05.02 and insert it into a Postgres 7
> > database using its str() value, it is stored as 03:04:05.01. Then when you
> > retrieve 03:04:05.01 from the database, the DateTime object shows it as
> > 03:04:05.00. Then you cannot match the row that you just retrieved with
> > its datetime column. How is the DateTime object supposed to be inserted
> > and retrieved from the database?
> The database interface should use the C API for this. It preserves
> the accuracy all the way. If that's not an option, I'd consider using
> the tuple representation now().tuple() which mimics
> time.localtime(time.time()) (but with added seconds accuracy).
> > I understand that a float cannot represent most decimal values exactly,
> > but truncating just increases the inaccuracy even though it might seem
> > more coherent to have "2002-03-28 10:59:59.9999" truncated to "2002-03-28
> > 10:59:59.99" instead of rounded to "2002-03-28 11:00:00.00".
> Hmm, one possibility would be to use rounding for all second
> values < 59.995 and apply truncation to all others.
Ok, I've change this now to have str(DateTime(...)) round seconds
to two decimal places with the exception of second values
>=59.995 and <60.00. The latter are all mapped to 59.99.
This may sound like a strange method, but in practice should
enhance accuracy when interfacing with other storage mechanisms
using string representations.
If anyone needs the old behaviour, I'll add a compile time
#define to switch back to the old behaviour.
CEO eGenix.com Software GmbH
Company & Consulting: http://www.egenix.com/
Python Software: http://www.egenix.com/files/python/
More information about the egenix-users