473,555 Members | 2,554 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Timestamp precision and rounding

(asked last week on .questions, no response)

Can anyone explain why this happens? (under 7.4.1)

select '2004-05-27 09:00:00.500001-04' :: timestamp(0) ;

timestamp
---------------------
2004-05-27 09:00:01
select '2004-05-27 09:00:00.500000-04' :: timestamp(0) ;

timestamp
---------------------
2004-05-27 09:00:00
That is, why doesn't the second operation result in the same timestamp
as the first? Is it a floating-point representation issue, or are the
mathematical rules of rounding not being followed correctly (as I
understand them, anyway)?

--
Jeff Boes vox 269.226.9550 ext 24
Database Engineer fax 269.349.9076
Nexcerpt, Inc. http://www.nexcerpt.com
...Nexcerpt... Extend your Expertise
Nov 23 '05 #1
6 4584

On Thu, 3 Jun 2004, Jeff Boes wrote:
(asked last week on .questions, no response)

Can anyone explain why this happens? (under 7.4.1)

select '2004-05-27 09:00:00.500001-04' :: timestamp(0) ;

timestamp
---------------------
2004-05-27 09:00:01
select '2004-05-27 09:00:00.500000-04' :: timestamp(0) ;

timestamp
---------------------
2004-05-27 09:00:00
That is, why doesn't the second operation result in the same timestamp
as the first? Is it a floating-point representation issue, or are the
mathematical rules of rounding not being followed correctly (as I
understand them, anyway)?


My first guess would be that your system probably implements its default
rounding as nearest even for .5 results, what does 9:00:01.5 give you?

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postg resql.org so that your
message can get through to the mailing list cleanly

Nov 23 '05 #2

Stephan Szabo <ss****@megazon e.bigpanda.com> writes:
That is, why doesn't the second operation result in the same timestamp
as the first? Is it a floating-point representation issue, or are the
mathematical rules of rounding not being followed correctly (as I
understand them, anyway)?
My first guess would be that your system probably implements its default
rounding as nearest even for .5 results, what does 9:00:01.5 give you?


Fwiw, the floating point timestamp representation is seconds-based. So 0.5s
should be exactly representable. (Though 0.500001 wouldn't, but that shouldn't
matter.)

On my machine it seems to always round away from 0, but this comment from
timestamp.c seems relevant. It would imply my build was build with integer
timestamps and yours was built with floating point timestamps:

/*
* Note: this round-to-nearest code is not completely consistent
* about rounding values that are exactly halfway between integral
* values. On most platforms, rint() will implement
* round-to-nearest-even, but the integer code always rounds up
* (away from zero). Is it worth trying to be consistent?
*/

And this is from the glibc Info page:
IEEE 754 defines four possible rounding modes:

Round to nearest.
This is the default mode. It should be used unless there is a
specific need for one of the others. In this mode results are
rounded to the nearest representable value. If the result is
midway between two representable values, the even representable is
chosen. "Even" here means the lowest-order bit is zero. This
rounding mode prevents statistical bias and guarantees numeric
stability: round-off errors in a lengthy calculation will remain
smaller than half of `FLT_EPSILON'.


[And the other rounding directions are useless;
this is the default and the only one that matters.]

--
greg
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postg resql.org

Nov 23 '05 #3

On Thu, 3 Jun 2004, Jeff Boes wrote:
(asked last week on .questions, no response)

Can anyone explain why this happens? (under 7.4.1)

select '2004-05-27 09:00:00.500001-04' :: timestamp(0) ;

timestamp
---------------------
2004-05-27 09:00:01
select '2004-05-27 09:00:00.500000-04' :: timestamp(0) ;

timestamp
---------------------
2004-05-27 09:00:00
That is, why doesn't the second operation result in the same timestamp
as the first? Is it a floating-point representation issue, or are the
mathematical rules of rounding not being followed correctly (as I
understand them, anyway)?


My first guess would be that your system probably implements its default
rounding as nearest even for .5 results, what does 9:00:01.5 give you?

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postg resql.org so that your
message can get through to the mailing list cleanly

Nov 23 '05 #4

Stephan Szabo <ss****@megazon e.bigpanda.com> writes:
That is, why doesn't the second operation result in the same timestamp
as the first? Is it a floating-point representation issue, or are the
mathematical rules of rounding not being followed correctly (as I
understand them, anyway)?
My first guess would be that your system probably implements its default
rounding as nearest even for .5 results, what does 9:00:01.5 give you?


Fwiw, the floating point timestamp representation is seconds-based. So 0.5s
should be exactly representable. (Though 0.500001 wouldn't, but that shouldn't
matter.)

On my machine it seems to always round away from 0, but this comment from
timestamp.c seems relevant. It would imply my build was build with integer
timestamps and yours was built with floating point timestamps:

/*
* Note: this round-to-nearest code is not completely consistent
* about rounding values that are exactly halfway between integral
* values. On most platforms, rint() will implement
* round-to-nearest-even, but the integer code always rounds up
* (away from zero). Is it worth trying to be consistent?
*/

And this is from the glibc Info page:
IEEE 754 defines four possible rounding modes:

Round to nearest.
This is the default mode. It should be used unless there is a
specific need for one of the others. In this mode results are
rounded to the nearest representable value. If the result is
midway between two representable values, the even representable is
chosen. "Even" here means the lowest-order bit is zero. This
rounding mode prevents statistical bias and guarantees numeric
stability: round-off errors in a lengthy calculation will remain
smaller than half of `FLT_EPSILON'.


[And the other rounding directions are useless;
this is the default and the only one that matters.]

--
greg
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postg resql.org

Nov 23 '05 #5
Stephan Szabo wrote:
On Thu, 3 Jun 2004, Jeff Boes wrote:
(asked last week on .questions, no response)

Can anyone explain why this happens? (under 7.4.1)

select '2004-05-27 09:00:00.500001-04' :: timestamp(0) ;

timestamp
---------------------
2004-05-27 09:00:01
select '2004-05-27 09:00:00.500000-04' :: timestamp(0) ;

timestamp
---------------------
2004-05-27 09:00:00
That is, why doesn't the second operation result in the same timestamp
as the first? Is it a floating-point representation issue, or are the
mathematica l rules of rounding not being followed correctly (as I
understand them, anyway)?


My first guess would be that your system probably implements its default
rounding as nearest even for .5 results, what does 9:00:01.5 give you?

2004-05-27 09:00:02, so I guess that would confirm it.
--
Jeff Boes vox 269.226.9550 ext 24
Database Engineer fax 269.349.9076
Nexcerpt, Inc. http://www.nexcerpt.com
...Nexcerpt... Extend your Expertise
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Nov 23 '05 #6
Stephan Szabo wrote:
On Thu, 3 Jun 2004, Jeff Boes wrote:
(asked last week on .questions, no response)

Can anyone explain why this happens? (under 7.4.1)

select '2004-05-27 09:00:00.500001-04' :: timestamp(0) ;

timestamp
---------------------
2004-05-27 09:00:01
select '2004-05-27 09:00:00.500000-04' :: timestamp(0) ;

timestamp
---------------------
2004-05-27 09:00:00
That is, why doesn't the second operation result in the same timestamp
as the first? Is it a floating-point representation issue, or are the
mathematica l rules of rounding not being followed correctly (as I
understand them, anyway)?


My first guess would be that your system probably implements its default
rounding as nearest even for .5 results, what does 9:00:01.5 give you?

2004-05-27 09:00:02, so I guess that would confirm it.
--
Jeff Boes vox 269.226.9550 ext 24
Database Engineer fax 269.349.9076
Nexcerpt, Inc. http://www.nexcerpt.com
...Nexcerpt... Extend your Expertise
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Nov 23 '05 #7

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

0
889
by: Jeff Boes | last post by:
Can anyone explain why this happens? (under 7.4.1) select '2004-05-27 09:00:00.500001-04' :: timestamp(0) ; timestamp --------------------- 2004-05-27 09:00:01 select '2004-05-27 09:00:00.500000-04' :: timestamp(0) ;
14
5811
by: calan | last post by:
Does anyone have a function that will round a number to 0 or .5? I have a form where I'm entering a number in inches. I need to round it to the nearest 1/2 inch (onChange). The split will be on increments of .25 22.24 = 22.0 22.25 = 22.5 22.52 = 22.5
5
2681
by: towers | last post by:
Hello, I've got a bit of experience in C++, but I'm writing my first app that is dependent on relatively precise math functions. The app requires that I get a time stamp based on s sample number, from a time series. This seems liek an easy thing to do: long lSample = 500; (for example) double dSampleRate = 1000.0;
3
3298
by: Claudio Lapidus | last post by:
Hello (Sorry about reposting, but I'm still not arriving to any good solution for this one) I need to output a timestamp attribute formatted to fixed-width, no spaces nor separators, something like test=> select to_char(timestamp '2003-10-24 15:30:59.999', 'YYYYMMDDHH24MISS');
1
2304
by: mboes | last post by:
Hi there, Is there a way of specifying the precision of a timestamp *with timezone* field? It works fine for timestamps *without* timezones, but gives me a syntax error if I try with timestamptz: tweag=> create table tbl1 (t timestamp(0)); CREATE TABLE tweag=> \d tbl1 Table "public.tbl1"
2
720
by: Zygo Blaxell | last post by:
I have a table with a few million rows of temperature data keyed by timestamp. I want to group these rows by timestamp intervals (e.g. every 32 seconds), compute aggregate functions on the columns, and ultimately feed the result into a graph-drawing web thingy. I'm trying a few different ways to get what seems to be the same data, and seeing...
29
3152
by: Marco | last post by:
Hello, I have : float f = 36.09999999; When I do : char cf; sprintf(cf,"%0.03lf", f); I get : 36.100
248
1510
by: md | last post by:
Hi Does any body know, how to round a double value with a specific number of digits after the decimal points? A function like this: RoundMyDouble (double &value, short numberOfPrecisions) It then updates the value with numberOfPrecisions after the decimal
1
3373
by: t8ntboy | last post by:
I am using ASP and SQL 2005 Express. I am inserting a timestamp from an ASP page using <%=now%into a smalldatetime field. All of my timestamps are appearing without any seconds (e.g., 1/21/2008 4:02:00 PM or 1/18/2008 11:32:00 AM). When I view the source for my page is shows the date/time as 1/21/2008 4:27:31 PM, but for some reason...
0
7903
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the...
0
6176
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then...
1
5452
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes...
0
5170
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert...
0
3593
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in...
0
3573
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
2034
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
1
1156
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
0
863
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.