You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Date: 2015-08-10 15:49:18 +0200
From: Richard Hughes <<richard.monetdb>>
To: SQL devs <>
Version: 11.19.15 (Oct2014-SP4)
CC: @njnes
Last updated: 2015-08-28 13:41:56 +0200
Comment 21113
Date: 2015-08-10 15:49:18 +0200
From: Richard Hughes <<richard.monetdb>>
The following query is a standard 'convert timestamp to UNIX time':
select now()-timestamp '1970-1-1';
On Oct2014-SP4 this gives:
sql>select now()-timestamp '1970-1-1';
+-------------------+
| current_timestamp |
+===================+
| 1439212945000 |
+-------------------+
1 tuple (1.520ms)
On Jul2015 e25934221162 this gives:
sql>select now()-timestamp '1970-1-1';
+-----------------------------------------------------------------------------+
| current_timestamp |
+=============================================================================+
| 1439212929.000 |
+-----------------------------------------------------------------------------+
1 tuple (1.414ms)
Was this silent behavioural change intentional?
The new result could be argued to be more correct (it's certainly better at hiding implementation details), but if you are going to stick with the change then please put a really big disclaimer in the release notes because I doubt I'm the only one who is going to get caught out.
A workaround appears to be "select cast(now()-timestamp '1970-1-1' as bigint);", which behaves the same on both versions.
(BTW, the epoch() function doesn't return milliseconds, so even in Jul2015 I won't be using it)
Date: 2015-08-10 15:49:18 +0200
From: Richard Hughes <<richard.monetdb>>
To: SQL devs <>
Version: 11.19.15 (Oct2014-SP4)
CC: @njnes
Last updated: 2015-08-28 13:41:56 +0200
Comment 21113
Date: 2015-08-10 15:49:18 +0200
From: Richard Hughes <<richard.monetdb>>
The following query is a standard 'convert timestamp to UNIX time':
select now()-timestamp '1970-1-1';
On Oct2014-SP4 this gives:
sql>select now()-timestamp '1970-1-1';
+-------------------+
| current_timestamp |
+===================+
| 1439212945000 |
+-------------------+
1 tuple (1.520ms)
On Jul2015 e25934221162 this gives:
sql>select now()-timestamp '1970-1-1';
+-----------------------------------------------------------------------------+
| current_timestamp |
+=============================================================================+
| 1439212929.000 |
+-----------------------------------------------------------------------------+
1 tuple (1.414ms)
Was this silent behavioural change intentional?
The new result could be argued to be more correct (it's certainly better at hiding implementation details), but if you are going to stick with the change then please put a really big disclaimer in the release notes because I doubt I'm the only one who is going to get caught out.
A workaround appears to be "select cast(now()-timestamp '1970-1-1' as bigint);", which behaves the same on both versions.
(BTW, the epoch() function doesn't return milliseconds, so even in Jul2015 I won't be using it)
Comment 21127
Date: 2015-08-12 14:20:03 +0200
From: @njnes
Yes its intentional and yes we should include a warning for this change.
Comment 21130
Date: 2015-08-12 14:27:39 +0200
From: @sjoerdmullender
(In reply to Niels Nes from comment 1)
Then please add a changelog message to sql/ChangeLog.Jul2015 (use Maddlog -f ...).
Comment 21157
Date: 2015-08-18 13:42:06 +0200
From: MonetDB Mercurial Repository <>
Changeset 8e113ab16cba made by Sjoerd Mullender sjoerd@acm.org in the MonetDB repo, refers to this bug.
For complete details, see http//devmonetdborg/hg/MonetDB?cmd=changeset;node=8e113ab16cba
Changeset description:
Comment 21195
Date: 2015-08-28 13:41:56 +0200
From: @sjoerdmullender
Jul2015 has been released.
The text was updated successfully, but these errors were encountered: