The ObjectScript $ZDATETIME function (also-know-as $ZDT) contains lots of options, some of which are close to what your want.  [[ Note $HOROLOG is also-known-as $H; $ZTIMESTAMP is aka $ZTS. ]]

$ZDT($H,3,1) gives the current local time, where character positions 1-10 contain the date you want and positions 12-19 contain the time you want.  However, character position 11 contains a blank, " ", instead of a "T".

$ZDT($ZTS,3,1) gives the current UTC time with character position 11 containing a blank.

    SET $EXTRACT(datetime,11)="T"
to your datetime result will fix the character position 11 issue.

Instead of using time format 1, you can use time formats 5  and 7 with $H.  $ZDT($H,3,5) gives local time in the format you want except character positions 20-27 contain the local offset from UTC.  $ZDT($H,3,7) converts the local $H date-time to UTC date-time and makes character position 20 contain "Z" to indicate the "Zulu" UTC time zone.  However, if your local time-zone includes a Daylight Saving Time (DST) offset change when DST "falls back" causing a local hour to be repeated then the time format 5 UTC offset or the time format 7 conversion from local to UTC will probably be incorrect during one of those repeated hours.

Although the above description says $ORDER scans "down" a multidimensional global, other programers might say it scans "sideways".  There are many different structures for databases.  E.g., there are network databases (sometimes called CODASYL databases); there are hierarchical databases (like ObjectScript multidimensional arrays/globals); there are relational databases (often accessed by the SQL language); ...

ObjectScript is based on the ANSI M language standard.  I believe that the name of the ANSI M hierarchical function $QUERY has always been $QUERY but the original name of the ANSI M hierarchical function $ORDER was formerly $NEXT.  $NEXT is very similar to $ORDER but $NEXT had problems with its starting/ending subscript values.  IRIS ObjectScript no longer documents the obsolete $NEXT function but the ObjectScript compiler still accepts programs using $NEXT for backwards compatibility.

Consider the following ObjectScript global array:


Consider the following walk sideways by $ORDER along the first subscript of ^g"

USER>set s=""
USER>for { SET s=$ORDER(^g(s))  QUIT:s=""  WRITE $NAME(^g(s)),! }    

Although these 4 globals contain values below them, the $ORDER walks did not walk down to deeper subscripts.  As it walked sideways, it returned the subscripts "b" and "d" even though ^g("b") and ^g("d") did not have values of their own but only values underneath them.

Now consider the walk down deeper by $QUERY through all the subscripts of ^g(...) at all subscript levels:

USER>set s="^g"
USER>for { WRITE s,!  SET s=$QUERY(@s)  QUIT:s="" }               

This walk by $QUERY was told to start at ^g and every call on $QUERY went through every subscripted node of ^g(...) that contained a value regardless of the number of subscripts needed.  However, elements ^g("b") and ^g("d") that did not contain values of their own were skipped by the $QUERY walk as it continued on to nodes with deeper subscripts that did contain values.

Also note that each $ORDER evaluation returned only a single subscript value as it walked sideways while each $QUERY evaluation returned a string containing the variable name along with all the subscript values of that particular multidimensional array node.

The ZZDUMP command is useful for debugging, especially when a searching for a bug caused by an unprintable character in an ObjectScript string.  The most recent versions of the ZWRITE command are now usually easier to use than the ZZDUMP command when they are used for debugging purposes.

One of the legacy uses for ZZDUMP was to look at corrupted strings, especially when a $LIST string had become corrupted by the use of some non-$LIST compliant string operations.  Back when I first joined InterSystems the documentation of ZZDUMP included a description of some of the $LIST formats so programmers could use ZZDUMP to see if a $LIST string was corrupted.  However, now ZWRITE will use $LB(...) syntax when a string contains a valid $LIST and it will use $C(i,j,k,l,...) in other cases when a string contains unprintable characters.  This makes ZWRITE a much better command than ZZDUMP when checking to see if a $LIST string is corrupted.  ZWRITE can recognize a compressed $BIT string but I have very little experience with how compressed $BIT strings are encoded.  Also ZWRITE can provide a translation of a %Status value.  ZWRITE will change further in the future as we discover additional useful display formats.

Back when ZZDUMP was documenting $LIST format that caused two types of problems:  (1) When new $LIST encodings were added there were complaints that older applications did not understand the new encodings; and (2) When the documentation described multiple encodings that could be used for the same data then the documentation did not include the complicated details about which encodings could be generated and which encodings could not be generated.  In general, when new $LIST encodings were generated as a replacement for older encodings then all the $LIST functions would still accept the older no longer generated encodings as well as the newer encodings for backwards compatibility.  Third party applications that used $LIST encodings without using the corresponding $LIST functions would be broken until they were modified to support both old and new encodings.  However, when there were new $LIST encodings that were not used in all possible cases then the $LIST functions may not properly decode that encoding in cases that were never generated.  Third party software would find that some $LIST functions would not work if third party software made a choice to use a $LIST encoding that had never been generated by the InterSystems supplied $LIST functions.  Having ZZDUMP no longer document $LIST formats resulted in a great reduction in such incompatibilities.

Publishing a full specification of the $LIST encodings complete with usage restrictions would allow ObjectScript to support programs that manipulated these encodings without being limited to using only the $LIST functions.  It would also freeze the $LIST encodings on existing data types and would not allow the specification to be extended to provide future optimizations.  On the other hand, supporting customer debugging often requires the exchange of information involving these internal specifications so we often ask customers to look at these encodings.  Discussing the encoding specifications in a debugging context is useful.  However, depending on the internal details of these specifications not changing in the future is much less useful and that is discouraged.

Steven has not followed anybody yet.
Global Masters badges:
Steven has no Global Masters badges yet.