query? Conditions using Scheduled Start/End Time and Current System Time

[Martyn Houghton]

Can I ask for clarification on how the decision branch condition will interpret doing a comparison between the current System Time obtained from the 'getLocalTime'  against a Request's Schedule Start and End datetime stamp values?

I am aware that the display of the Request's Schedule Start and End datetime stamp values will be done using the session Timezone, but held in the database in UTC timezone (Zulu time), but does the condition statement also apply this translation or should I be setting the 'getLocalTime' node to return this as UTC?

Cheers

Martyn

 

[Victor]

55 minutes ago, Martyn Houghton said:

should I be setting the 'getLocalTime' node to return this as UTC?

@Martyn Houghton you mean GMT and I would say yes. The reason would be that "Scheduled Start Date" will have the GMT value thus you will need a(nother) GMT value to compare this against...

If I am not mistaken, Get Timestamp utility (from an integration node) will also return the GMT/UTC time at the time when it's run..

[Martyn Houghton]

@Victor

We operate in a number of timezones, so are you saying the value held in the 'h_itsm_changerequests' in fields 'h_start_date' and h_end_time' are held in a local timezone value or are they held in UTC and translated to the local timezone ahead of using them for the condition statement? I think it the latter but just want to confirm.

Would I be correct in assuming leaving the 'getLocalTime' timzone paramater as Ignore or Auto - would get return the current datetime stamp in the same timezone as that being presented to the condition statement. Is there any difference between setting this to Ignore or Auto?

Cheers

Martyn

 

[Victor]

@Martyn Houghton

21 minutes ago, Martyn Houghton said:

are they held in UTC

All date/time values are stored in the database as GMT using UTC format.

22 minutes ago, Martyn Houghton said:

translated to the local timezone ahead of using them for the condition statement

No. There is no formatting or translation here. The date/time values are only formatted to a timezone in the UI. The workflow is not UI (for the purpose of this exercise) thus it will use the database value, which is GMT.

23 minutes ago, Martyn Houghton said:

Would I be correct in assuming leaving the 'getLocalTime' timzone paramater as Ignore or Auto - would get return the current datetime stamp in the same timezone as that being presented to the condition statement.

No. Or not quite. Left to ignore, it will return the date in the timezone of the user in which context the operation runs. If the user is, for example, SYS_BMP_MANAGER (the internal system user for workflow actions) then the timezone is whatever timezone is set for this user. In this example, it will be GMT but workflow actions are performed in different user contexts which means possibly a different timezone, therefore we would need an approach to ensure this is not variable.

28 minutes ago, Martyn Houghton said:

Is there any difference between setting this to Ignore or Auto?

Yes. Set to ignore will do the above. Set to Auto might do the above unless the workflow has a(nother) previous node that outputs a param as 'getLocalTime'. If there is such a node, then any subsequent nodes that have an input param as  'getLocalTime' will inherit the value of the initial node that did output a value for this param. This is valid for any node, any param that is using the Auto value.

[Martyn Houghton]

@Victor

12 minutes ago, Victor said:

All date/time values are stored in the database as GMT using UTC format.

If the values are always stored as GMT, are these translated by the UI to GMT if being entered on the change request by a user who timezone if not GMT, such as IST?

Also if they are always stored as GMT, would it not be best to set the timezone parameter to on the getLocalTime to GMT, thus ensuring the values being compared by the condition are the same timezone?

Thanks.

Cheers

Martyn

[Victor]

8 minutes ago, Martyn Houghton said:

If the values are always stored as GMT, are these translated by the UI to GMT if being entered on the change request by a user who timezone if not GMT, such as IST?

Yes. But not by the UI though, they are "translated" by the API that does the db update prior to the value being stored.

9 minutes ago, Martyn Houghton said:

would it not be best to set the timezone parameter to on the getLocalTime to GMT, thus ensuring the values being compared by the condition are the same timezone?

Yes. That would be what I said above in my initial reply...  

[Martyn Houghton]

@Victor

Is there any documentation on the TimeZone [string] values the Get Local Time node will accept as getting an error when setting it to GMT?

Cheers

Martyn

 

[Victor]

@Martyn Houghton try: GMT Standard Time

[Martyn Houghton]

@Victor

'GMT Standard Time' works, however from debugging our process we need to undertake the custom expression evaluation using UTC. We have tried 'UTC' and 'UTC Standard Time' as string values for the timezone but both of these cause the node to fail.

FYI this is the info when used the Timezone 'GMT Standard Time' and you can see the Scheduled time as a variable is returned as UTC.

Cheers

Martyn

 

[Victor]

@Martyn Houghton why not use the Seed Time then?

[Martyn Houghton]

@Victor

So just to confirm Seed Time will always return UTC?

Cheers

Martyn

[Victor]

@Martyn Houghton yes, should always return UTC time.