If I understood the question correctly I think there might be some confusion...

Indeed internally Ensemble stores the Message Header times (TimeCreated & TimeProcessed) in a UTC time (per the considerations Robert mentioned) but when these times are displayed in the Message Viewer they go through conversion and are displayed in local time.

So if you would open the object via code, or run an SQL query directly, you would be dependent on running the relevant LogicalToDisplay() or LogicalToOdbc() methods for objects, or using the ODBC or Display runtime modes, but on the default Message Viewer web page these times should appear local.

You can examine this by doing a simple select on the Message Header table and you can see the difference between the Logical and Display modes.

For example, for a certain message, the Logical (internal UTC) time is 10:42 -

And now the same time using Display mode, the time is 13:42 -

And compare this with what you see in the Message Viewer, you see 13:42 -

and -

Note if you take a look at the Ens.DataType.UTC data-type class you can see it's conversion methods.

For example the LogicalToDisplay() method.

Here's an example of what it looks like when it's code runs.

In the following code I show my current local time (using $H, taking into account Time Zone and Daylight Saving), then I show the current general time (using $ZTS, per GMT and no Daylight Saving), and then applying the code run by the method, calling the method, and explicitly.

TEST>set currentLocalTime = $ZDateTime($Horolog,3,,3) 

TEST>set currentGeneralTime = $ZDateTime($ZTimeStamp,3,,3) 

TEST>write currentLocalTime
2018-09-20 10:46:07.000 

TEST>write currentGeneralTime 
2018-09-20 07:46:15.107 

TEST>write $zdatetime($zdTH($zdatetimeh(currentGeneralTime,3,,,,,,,,0),-3),3,,3) 
2018-09-20 10:46:15.107 

TEST>write ##class(Ens.DataType.UTC).LogicalToDisplay(currentGeneralTime) 
2018-09-20 10:46:15.107

See the -3 argument in the $ZDTH function call, from the docs this does the following -

$ZDATETIMEH takes a datetime value specified in $ZTIMESTAMP internal format, converts that value from UTC Universal time to local time, and returns the resulting value in the same internal format

Hi Dmitry,

Recommending your very cool and useful utility to someone I realized I did not find installation instructions, not here in this article, nor in the GitHub readme.

Could you please point me to them, or in case they indeed do not exist currently can you please provide them, for the benefit not only of the person I'm sharing this with, but with other Community members who will want to use this in the future. 

Tx!

Happy this helped.

In general (you might be aware of this, but for the benefit of the Community) a good resource about searching Messages (including Search Tables and SQL, and other options), is this Online Course.

The issue of indexing data previously processed (before the Search Table was defined for the Business Service/Operation) is addressable by calling the BuildIndex() method of the relevant SearchTable class.

For example:

Set sc=##class(YourPackage.YourSearchTableClass).BuildIndex()

Please note that by default when a Persistent instance is %Saved()'d it gets done inside a Transaction, and therefore, even if the Database the Class' storage globals' are in, is not journaled, these SETs (and KILLs) will get journaled (for supporting rollback).

See this article for more details regarding avoiding journaling data. Specifically - the options of using CACHETEMP or turning off transactions for object filing.

Note if you are concerned with the audit logs generated for every turning off and on the journal for your process - you could simply turn off that System Audit event - %System/%System/JournalChange. Taking of course into consideration the drawback of not logging these kind of events outside the context of this specific scenario.

Regarding Samples see also from the InterSystems IRIS documentation:

Downloading Samples for Use with InterSystems IRIS

John, 

It seems the link to the documentation you provided above is now broken (and yields an error page; it possibly worked in a previous version's docs).

I assume you meant this page:

http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GCNV_C176399

Note that apart from Export and Import options -

If you are using a %Installer Manifest for your deployment (for any environment - test or prod) - you can include in that manifest also the creation of Security elements such as Resources and Roles, etc.

For example:

<Resource
    Name="%accounting_user" 
    Description="Accounting"
    Permission="RW"/>

And:

<Role 
    Name="%DB_USER"
    Description="Database user"
    Resources="MyResource:RW,MyResource1:RWU"
    RolesGranted= />

See more information here (in the docs).

[Defining a Role as part of a manifest is also included in an example in [@Eduard Lebedyuk]'s post here]

Nikita, this is really an excellent tool.

One question: The documentation states that Web Terminal is supported from version 2013.1 and up of Caché (Ensemble, etc.). But it seems (at least v4) to require functionality (e.g. %CSP.REST) that exists only in newer versions than 2013.1.

I assume older versions of Web Terminal supported 2013.1.

Could you please restate what is the minimal Caché version for v4 of Web Terminal, and what is the latest version of Web Terminal that did support Caché v2013.1.

(And perhaps update for every ("released") version of Web Terminal which is the minimal required Caché version.)

Thanks!