I agree with @Brett Saviano:
$$$  ...refers to some #define ...  and is a compiler directive

I tried:

USER>:alias wi write "/csp/"_$zcvt($namespace,"L")
 
USER>:wi
write "/csp/"_$zcvt($namespace,"L")
/csp/user
USER>:alias wi1 write "/csp/"_$$$LOWER($namespace)
 
USER>:wi1
write "/csp/"_$$$LOWER($namespace)
 
WRITE "/csp/"_$$$LOWER($namespace)
^
<SYNTAX>
USER>

• my personal preference goes to %GSIZE. The best match between CONSUMED and ALLOCATED size is found if your Global is "filled" total sequentially by a $Q() loop. And even then with a big string, you may force unexpected block splits. The situation changes if you fill your globals by subscript levels. This may cause a cascade of block splits and result  in rater unattractive packing percentages  
• ALLOCATED Size by Subscript might be of interest for an individual Subscript. Though adding them up doesn't reflect the total size It's like cutting a cake to 12 people and then counting the heads that had some cake.  
• to reduce the space consumption of your globals I rather suggest to  use ##Class(%GlobalEdit).GloabelCompact()  to eliminate the effects of random inserts and growth inside a global tree.   

👍 SUPER 💪

my guess by following docs
 

USER>:alias pp do ##class(%ASQ.SetUtils).pp("$1")

from my local Class docs:

GetGlobalSizeBySubscript
This method will return the size of a global based on the number of database blocks the global resides in.

so you get blocks * blocksize ===> ALLOCATED size
Depending on Packing as %GSIZE shows   The difference might be significant

Summary by Subscript will most likely show higher values as a pointer block
or even a data block (eg. with 8kb) may contain more than a single subscript
depending on the Global structure.
Take the default top subscript  (aka. IDKEY) for Caché classes (Integer, >0) as an example ​​

tSC is mostly a %Status object
with enough experience Zwrite tells you all you want and need to know
$SYSTEM.Status.DisplayError(tSC) is easier read.  a matter of comfort

Thanks for the recognitions!  😀🖐
It's a very strong motivation to be productive.
Often to distract from personal struggles.
Many thanks to the DX+OEX+GM team for their help! 👏 🌸🌼🌹🌻💐

in the previous screenshot you see the namespace as a blue link
and the names of the DB in the yellow highlighted  
 

check if the date object  var d=new Date();
is inside your routine or at least globally defined

like this

take a look to Mgmt Portal and check NAMESPACE definition
to see DB-file vs. Namespace.
In your case, I'd create a new namespace based on your DB-file to avoid conflicts.
>>> the same Db for Routine (=code) and Globals

applying  

• WITH STORAGETYPE = COLUMNAR

as last line  item seems to work (as found in Docs)

Big CONGRATULATIONS to all winners !
It's a pleasure to follow your contributions.

right. 2013.1 was the last chance

%Studio.Project).InstallFromGbl(...  rejects explicitly for Versions before 2013.1 in line 1440

• ...   ("VERSION")),".",1,2)<2013.1  ..... 
• ...  Set sc=$$$ERROR($$$DplyVersion, .....
• %occErrors.inc(2547): #define DplyVersion 7602

You better contact WRC for help  with this 10 year old version

Bonsoir Sylvain!
Are you looking for something similar to this;
 

Property MonJour As %String 
     [ InitialExpression = "31/12/1840" ];

Property Jour As %Date [ InitialExpression = 0,
  SqlComputeCode = {set {*}= $ZDH({MonJour},4) },
  SqlComputed, SqlComputeOnChange = MonJour ];
 

(Multiline just for readability)

 

Thanks for the test data!
It confirms known behavior:

• Oracle takes a lot of effort to prevent straightforward comparisons
• But over decades, I haven't ever seen them winning against IRIS / Caché.
• OK, and PostgreSQL or MySQL never was competitive,

Great job !