#1 is correct

Your calculation #2 is seriously wrong.
reason
reading documentation you see
dformat -2 

And that's the mistake:
Your BirthDate is obviously considered as  LOCAL time
And therefore the difference you see reflects the time offset of your machine to UTC

-19800 sec => -5.5 hrs
system variable $ZTZ will show your offset to UTC in minutes  => -330
my guess: your machine is running at local time in India

 

for $ZTDH:
https://docs.intersystems.com/iris20231/csp/docbook/DocBook.UI.Page.cls?KEY=RCOS_fzdatetimeh
for $ZDT:
https://docs.intersystems.com/iris20231/csp/docbook/DocBook.UI.Page.cls?KEY=RCOS_fzdatetime

USER>r x
1997-08-09 10:38:39.700000000
USER>w $ZDTH(x,3,,9)
57199,38319.7
USER>w $zdt($ZDTH(x,3,,9),3,7)
1997-08-09T08:38:39Z
USER>w $zdt($ZDTH(x,3,,9),3,7,9)
1997-08-09T08:38:39.700000000Z
USER>

what you describe is explained in detail in the documentation:
%SQL.StatementResult

For a SELECT statement, if the cursor is positioned after the last row, the value of %ROWCOUNT indicates the number of rows contained in the result set.
At any other time, %ROWCOUNT contains the number of rows retrieved thus far. 

rfm

win docker desktop not just consumes fast-growing  vhdx
but also a lot of temp files, that get never deleted or shrinked
not even with deinstall / reinstall
typically in 
C:\Users\<usename>\AppData\Local\Temp\docker-scout\sha256 
C:\Users\<username>\.docker\scout\sbom\sha256
C:\Users\<username>\AppData\Local\Temp\  *.ico, *.vhdx

in Caché it is %installdir%/mgr/cconsole.log
and you can see it from MgmtPortal
and it would be helpful if you uncover the primary language you use

in your namespace you can map not just full Globals   
to a different Database but also parts of a Global.
This works over Global Subscript   Details

IF your structure is ^HISTORY(yyyymm, ....)    [yyyymm as first subscript ]
? eventually also your IDKEY ?
this is a possible way   to set   
^HISTORY(201606) >>  201606_HIPAA.dat 
^HISTORY(201607) >>  201607_HIPAA.dat

But if yyyymm is just somewhere in your data, you need to reorganize your global
I assume this is something  you have to do anyhow with your history 

ATTENTION: this is total static.
so for 120 DBs you need 120 mapping lines

If not disabled all global SET and KILL and also transactions are documented in JOURNAL
there are also related search utilities available in %SYS
there is no equivalent feature for Global READ.

if you just look for the fact that there was a SET or KILL at object level
DSTIME could be an option see example: 
https://community.intersystems.com/post/synchronize-data-dstime
it is easier to handle than JOURNAL


 

see doc on Variable Number of Parameters

Summary:

1. args = number of params passed
2. args(n) = n-th param
3. modify as you need, it's just a local variable

Just to rephrase your issue:

• you expect a JSON array of JSON objects   [{..},{..},{..} ]
• but you get a JSON object containing that array {"cursos": [{..},{..},{..} ]}

;;  asssumptio input holds the received obj
    set jobj={}.%FromJSON(input) ; convert to obj
    set jarray=jobj.%Get("cursos")   ; content of "cursos" = [..]
    set output=jarray.%ToJSON() ; convert to  string
    

docu: %Library.DynamicObject
 

ClassMethod SortVersion(input As %DynamicArray) As %DynamicArray {
    Set sorted = []
    Set val = ""
    Kill order
    For i=1:1:input.%Size() Set order(input.%Get(i-1))=""
    For  {
        Set val=$o(order(val)) Quit:val=""
        do sorted.%Push(val)
        }
   Quit sorted
}

I have a straight Caché only Docker available for you:
Here is the GitHub Repo until publication on OEX is approved

If you need Caché in Docker you may use this example
https://community.intersystems.com/post/using-ecp-across-iris-and-cach%C3%A9
An individual license is only required if you want to use ECP
It's the single user version 2018.*   and should fit your needs

MUCH more simple and shorter
 

kill
set a=##class(Sample.Person).%OpenId(2)
set b=##class(Sample.Person).%OpenId(12)
set c=##class(Sample.Person).%OpenId(111)

set obj=$zobjref("2@Sample.Person")

;; BINGO

zw
 
a=<OBJECT REFERENCE>[1@Sample.Person]
b=<OBJECT REFERENCE>[2@Sample.Person]
c=<OBJECT REFERENCE>[3@Sample.Employee]
obj=<OBJECT REFERENCE>[2@Sample.Person]

if you take a look to method ##class(EnsLib.HL7.Segment).getAtFromArray(...)
you see that the segment data is assembled in row 1008 of the class by  Set data=data_value 
without checking the size.
So it is designed to fail with large documents as your Base64 encoded PDF (~+33% of original)
So just using a reference to an external stored file as you suggested should work. 
 

BTW datatype %VarString is just a shortcut of %String(MAXLEN="") and a sometimes appropriate SQLTYPE.
 

by using {}  your Jsonobj is already a  %Library.DynamicObject
USER> ZWRITE Jsonobj
Jsonobj=<OBJECT REFERENCE>[1@%Library.DynamicObject]

no need for 
Set Dynjsonobj=##class(%Library.DynamicObject).%FromJSON(Jsonobj)

it's $zhex("A3")  or $c(163)  according to  this source

$system.Util.InstallDirectory()

classmethod InstallDirectory() as %String

Returns the location of the installation directory, i.e. that which is displayed by ccontrol on Unix and VMS, where the .cpf configuration file is kept.

If you are not afraid of using basic COS functionality:
your reload method raises a LOCK ^myRELOAD  
and drops it with completion LOCK -^myRELOAD

Your check utility does the same but with a timeout LOCK ^myRELOAD:0
if it fails - signaled by $TEST=0  you loop and hang around and retry
for success $TEST=1 you go on but release your successful LOCK immediately
not to block anyone else.