Re: [NOVICE] Postgres storing time in strange manner - Mailing list pgsql-bugs

From Bruce Momjian
Subject Re: [NOVICE] Postgres storing time in strange manner
Date
Msg-id 200209172213.g8HMDVS26563@candle.pha.pa.us
Whole thread Raw
In response to Re: [NOVICE] Postgres storing time in strange manner  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [NOVICE] Postgres storing time in strange manner  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
Tom Lane wrote:
> Ron Johnson <ron.l.johnson@cox.net> writes:
> > Out of curiosity: why does -ffast-math break the datetime rounding code?
>
> We dug into this last night, and it turns out that the culprit is code
> like
>
>     int hour = time / 3600;
>
> where time is a double.  This yields an exact result when done
> correctly, but with -ffast-math gcc will "improve" it to
>
>     int hour = time * 0.000277777777777778;
>
> the constant being the nearest double value to 1.0 / 3600.0.  The
> problem is that the constant is inexact and in fact is slightly too
> large; so for example if time is exactly 18000.0, you get a resulting
> hour value of 4, not 5, after truncation to integer.  Repeated a couple
> more times, what should have been 5:00:00 comes out as 4:59:60 ...

Hard to imagine why anyone would want such an optimization.  How much
faster could it possibly be?  I guess if you were doing only complex
math approximations, it would be a win, but that isn't really proper for
a database.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: [NOVICE] Postgres storing time in strange manner
Next
From: Tom Lane
Date:
Subject: Re: [NOVICE] Postgres storing time in strange manner