When returning epoch dates out of MSSQL we need to use DATEDIFF function:
in a query, using the T-SQL function DATEDIFF(SECOND,'1970-01-01',getdate()) returns an int and this is correctly returned as a number in the result in node-red.
However, the T-SQL function DATEDIFF_BIG(SECOND,'1970-01-01',getdate()) returns a bigint, and this is being returned as a string in node-red.
Seems completely repeatable.
Of course we can use parseInt() to convert the string to a number, but the above is an inconsistency better fixed internally please.
In the case of epoch dates, this Is of significance:
a) If you want to return a full milliseconds epoch date as in DATEDIFF_BIG(MILLISECOND,'1970-01-01',getdate()) then you have to use DATEDIFF_BIG or you get an overflow.
b) All epoch dates in seconds after 2038-01-19 03:14:07 will be too big for an int data type (a 4 byte integer) so we should become accustomed to using DATEDIFF_BIG in T-SQL to produce epoch dates.
When returning epoch dates out of MSSQL we need to use DATEDIFF function:
in a query, using the T-SQL function DATEDIFF(SECOND,'1970-01-01',getdate()) returns an int and this is correctly returned as a number in the result in node-red.
However, the T-SQL function DATEDIFF_BIG(SECOND,'1970-01-01',getdate()) returns a bigint, and this is being returned as a string in node-red.
Seems completely repeatable.
Of course we can use parseInt() to convert the string to a number, but the above is an inconsistency better fixed internally please.
In the case of epoch dates, this Is of significance: a) If you want to return a full milliseconds epoch date as in DATEDIFF_BIG(MILLISECOND,'1970-01-01',getdate()) then you have to use DATEDIFF_BIG or you get an overflow. b) All epoch dates in seconds after 2038-01-19 03:14:07 will be too big for an int data type (a 4 byte integer) so we should become accustomed to using DATEDIFF_BIG in T-SQL to produce epoch dates.
Great node otherwise - thankyou for making it..
Richard