Date: 2017-10-02 14:57:08 +0200
From: Manuel <>
To: SQL devs <>
Version: 11.25.23 (Dec2016-SP5)
CC: @njnes
Last updated: 2017-11-01 16:41:06 +0100
Comment 25677
Date: 2017-10-02 14:57:08 +0200
From: Manuel <>
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36
Build Identifier:
If I call sys.epoch function on date beyond 19-01-2038 03:14:00, what I get back is a negative number. I understand that this is an overflow issue, but currently there is no work-around for this problem in monetdb.
Reproducible: Always
Steps to Reproduce:
select sys.epoch(str_to_timestamp('19-01-2038 03:15', '%d-%m-%Y %H:%M')) AS "timestamp";
Actual Results:
-2147483596
Expected Results:
2147483700
I am actually using sys.epoch to evaluate the mean (avg) over a date column: Is there an alternative workaround for that ?.
Date: 2017-10-02 14:57:08 +0200
From: Manuel <>
To: SQL devs <>
Version: 11.25.23 (Dec2016-SP5)
CC: @njnes
Last updated: 2017-11-01 16:41:06 +0100
Comment 25677
Date: 2017-10-02 14:57:08 +0200
From: Manuel <>
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36
Build Identifier:
If I call sys.epoch function on date beyond 19-01-2038 03:14:00, what I get back is a negative number. I understand that this is an overflow issue, but currently there is no work-around for this problem in monetdb.
Reproducible: Always
Steps to Reproduce:
select sys.epoch(str_to_timestamp('19-01-2038 03:15', '%d-%m-%Y %H:%M')) AS "timestamp";
Actual Results:
-2147483596
Expected Results:
2147483700
I am actually using sys.epoch to evaluate the mean (avg) over a date column: Is there an alternative workaround for that ?.
Comment 25720
Date: 2017-10-15 11:32:17 +0200
From: @njnes
given the current data type (int) used an error should be given by the epoch function. Somehow we need to switch to BIGINT.
Comment 25834
Date: 2017-11-01 16:41:06 +0100
From: Manuel <>
(In reply to Niels Nes from comment 1)
Would it be possible to introduce a new function returning a bigint ?
The text was updated successfully, but these errors were encountered: