So you have to examine this special record in detail in the underlying Global.
Seems to be a broken record that you hit by accident.

OK. this looks like the first record you find is already in trouble.
I'd expect your data type is something else then stored.
Next omit the conversion %ODBCOUT()  just to see what internal content is and where it starts

  select ID,%INTERNAL(VerzamelDatTijd),
        DateTijdSec from GLPPatTcActie
         where pnr = '27085070017'
         and LTestId->Makey='BLA'
         and glpactieid->makey in ('TAV','TMA') 

The next question is of course which program writes these values? and how? what's the source?

I get more and more the impression that some 'aged' program writes directly into the global.
Probably directly some $HOROLOG which is a combined %DATE,%TIME construct.
 

OK!
Now I see the problem. Each datatype has its specific conversion from internal format to ODBC format
So if VerzamelDatTijd is %Date or %Time or %Timestamp and the stored content doesn't fit
you get most likely this error.
It could be by principle := it fits never, a design issue
It could be just a glitch in some data record.
I suggest you start the SQL shell from terminal prompt.  USER>do $system.SQL.Shell()
And then run your modified query:

select  ID,%INTERNAL(VerzamelDatTijd),%ODBCout(VerzamelDatTijd),DateTijdSec
from  GLPPatTcActie 
 where pnr = '27085070017' and LTestId->Makey='BLA'
-- and VerzamelDatTijd < '2021-03-04 09:04'
and glpactieid->makey in ('TAV','TMA')
-- order by DateTijdSec desc

ID shows the flaky record
%INTERNAL() shows the raw content
%ODBCOUT() should trigger the error

Once you know the content you should be able to fix it.

what date time format would you expect this to be ???? 

'2021-03-04-2021 09:04'  

YYYY-MM-DD-YYYY HH:mm

Not really standard! Rather a wrong DateTime in your Query !

for Caché ODBC/JDBC drivers are part of standard distribution since ever

%installdir%/bin/CacheODBC.dll
%installdir%/bin/CacheODBC64.dl

Or use your Caché distribution kit and run a custom install with ODBC only

Well,

You can either use default SQL function UPPER() or LOWER() to force a specific case. e.g:

SELECT * FROM erp.Teste2 WHERE 
$TRANSLATE(LOWER(firstname),'áéíóúçâêîôû','aeioucaeiou') like 'fabio'

or 

SELECT * FROM erp.Teste2 WHERE 
$TRANSLATE(UPPER(firstname),'ÁÉÍÓÚÇÂÊÎÔÛ','AEIOUCAEIOU') like UPPER('Fabio')

using SQL you can compare the last change between definition and compilation of classes
a negative difference shows where recompilation is required.
I used Posix-Timeformat for an easier compare

SELECT 
def.ID, cmp.TimeChanged compiled,  def.TimeChanged defined, 
to_char($piece(cmp.TimeChanged,',',1),'J')-to_char($piece(def.TimeChanged,',',1),'J') diff
FROM %Dictionary.ClassDefinition def
left outer join %Dictionary.CompiledClass cmp
on def.ID=cmp.ID
where NOT def.name %startswith '%'
order by 4

This list can be grouped into 3.5 categories:

• Installation and Configuration  happens typically once and will not change under normal operation
  • InterSystems IRIS license key
  • Configuration Parameter File
  • Databases
  • Namespace interoperability settings

• Code management and change happens rarely and mostly not during full operation. the dependency of server environment might be required (mixed OS e.g. WIN - AIX)
  • Custom code in %SYS namespace
  • CSP, JS, and CSS files
  • External linked libraries and custom shared libraries

• Almost  Runtime changes
  • Security settings (including users, roles, resources, services, and applications)

• Runtime changes
  • Task Manager tasks

Only the last 2 are critical for successful mirror failover and require dynamic handling
and the last requires also non-stop monitoring as it is not directly triggered by SysAdmin.

Just any Select.   e.g. 
          SELECT 17+4 as BlackJack, NOW() as TimeToWin
no table required
or
          SELECT Top 5 *  FROM %TSQL_sys.types