In the database, a table has this column: Blarg datetime(3) default current_timestamp(3)
So, select Blarg from atable yields a result like these:
2021-11-23 04:58:22.391 <-- okay
2021-11-23 04:58:22.32 <-- parses as localtime, so for me, is 8 hours off
It's a nasty bug, happening approx 1 in 10 times - because 320 milliseconds is .320, and the trailing insignificant 0 is removed.
The bug in data-api-client is in this code:
// Converts the string value to a Date object.
// If standard TIMESTAMP format (YYYY-MM-DD[ HH:MM:SS[.FFF]]) without TZ + treatAsLocalDate=false then assume UTC Date
// In all other cases convert value to datetime as-is (also values with TZ info)
const formatFromTimeStamp = (value,treatAsLocalDate) =>
!treatAsLocalDate && /^\d{4}-\d{2}-\d{2}(\s\d{2}:\d{2}:\d{2}(\.\d{3})?)?$/.test(value) ?
new Date(value + 'Z') :
new Date(value)
Personally, I'd probably change that last \d{3} to \d+ to fix the problem
Also: datetime(6) would almost always be treated incorrectly, and the above regex change would fix it too.
In the database, a table has this column:
Blarg datetime(3) default current_timestamp(3)
So,
select Blarg from atable
yields a result like these:2021-11-23 04:58:22.391
<-- okay2021-11-23 04:58:22.32
<-- parses as localtime, so for me, is 8 hours offIt's a nasty bug, happening approx 1 in 10 times - because 320 milliseconds is
.320
, and the trailing insignificant0
is removed.The bug in data-api-client is in this code:
Personally, I'd probably change that last
\d{3}
to\d+
to fix the problemAlso:
datetime(6)
would almost always be treated incorrectly, and the above regex change would fix it too.