Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SQL: time with precision #2873

Closed
monetdb-team opened this issue Nov 30, 2020 · 0 comments
Closed

SQL: time with precision #2873

monetdb-team opened this issue Nov 30, 2020 · 0 comments
Labels
bug Something isn't working normal SQL

Comments

@monetdb-team
Copy link

Date: 2011-08-30 23:43:26 +0200
From: @yzchang
To: SQL devs <>
Version: 11.5.3 (Aug2011-SP1) [obsolete]

Last updated: 2012-01-26 15:31:55 +0100

Comment 16179

Date: 2011-08-30 23:43:26 +0200
From: @yzchang

Some queries envovling time values with precision produce wrong results.

$ mserver5 --set mapi_port=50001
MonetDB 5 server v11.3.8
This is an unreleased version
Serving database 'demo', using 4 threads
Compiled for x86_64-unknown-linux-gnu/64bit with 64bit OIDs dynamically linked
Found 7.749 GiB available main-memory.
Copyright (c) 1993-July 2008 CWI.
Copyright (c) August 2008-2011 MonetDB B.V., all rights reserved
Visit http://www.monetdb.org/ for further information
Listening for connection requests on mapi:monetdb://127.0.0.1:50001/
MonetDB/GIS module loaded
MonetDB/SQL module loaded

SQL catalog created, loading sql scripts once

sql>create table t (tm time);
operation successful
sql>insert into t values ('20:04:04.847');
1 affected row (1.176ms)
sql>select tm + interval '0' second from t;
+-----------------+
| sql_add_tm |
+=================+
| 20:04:04.847000 |
+-----------------+
1 tuple (1.673ms)

-- The result should be: 20:04:04
-- since the default precision of TIME is 0

sql>select tm + interval '0.333' second(5) from t;
+-----------------+
| sql_add_tm |
+=================+
| 20:04:04.847000 |
+-----------------+
1 tuple (1.669ms)

-- should be: 20:04:04.333000

sql>select time '20:04:04.847' - time '20:04:04.947';
+----------------------+
| sql_sub_single_value |
+======================+
| 00:00:00.847000 |
+----------------------+
1 tuple (0.771ms)

-- should be: 000000000000

sql>select time(5) '20:04:04.947' - time(5) '20:04:04.847';
+----------------------+
| sql_sub_single_value |
+======================+
| 00:00:00.947000 |
+----------------------+
1 tuple (0.944ms)

-- should be: 00:00:00.100000

Comment 16180

Date: 2011-08-30 23:53:01 +0200
From: @yzchang

Changeset f2acd8b59d7a made by Jennie Zhang y.zhang@cwi.nl in the MonetDB repo, refers to this bug.

For complete details, see http//devmonetdborg/hg/MonetDB?cmd=changeset;node=f2acd8b59d7a

Changeset description:

Added test for bug #2873

Comment 16181

Date: 2011-08-31 18:56:29 +0200
From: @njnes

Changeset 2d9beef3e6f5 made by Niels Nes niels@cwi.nl in the MonetDB repo, refers to this bug.

For complete details, see http//devmonetdborg/hg/MonetDB?cmd=changeset;node=2d9beef3e6f5

Changeset description:

changes/fixes
	interval seconds now stores milli - seconds
	handle sub-second fractions

TIME, TIMESTAMP and INTERVAL (second) have time precision
time defaults to 0 (ie not smaller than seconds)
timestamp and interval default to 6 but monet only supports 3 (ie allways
3 zero's at the end)

fixes bug #2873 and old feature request 2415

Comment 16270

Date: 2011-09-16 15:10:36 +0200
From: @sjoerdmullender

The Aug2011 version has been released.

Comment 16389

Date: 2011-10-07 16:32:33 +0200
From: @sjoerdmullender

Niels implemented a fix for the next release.

Comment 16814

Date: 2012-01-26 15:31:55 +0100
From: @sjoerdmullender

The Dec2011 version has been release, so declaring this bug as FIXED.

@monetdb-team monetdb-team added bug Something isn't working normal SQL labels Nov 30, 2020
@sjoerdmullender sjoerdmullender added this to the Ancient Release milestone Nov 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working normal SQL
Projects
None yet
Development

No branches or pull requests

2 participants